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(54) MOBILE COMMUNICATION METHOD AND MOBILE COMMUNICATION SYSTEM 



(57) When a network pages the temporary user 
mobile identifier of a mobile station, the mobile station 
sends a response to the network. Next, the network 
checks the authenticity of the user using a ciphering 
key, corresponding to the temporary user mobile identi- 
fier and a random number. If the temporary user mobile 
identifier is authenticated, a normal incoming call 
acceptance procedure is executed. If the mobile station 
is authenticated although the temporary user mobile 
identifier is wrong, the network reassigns a new tempo- 
rary user mobile identifier to the mobile station and 
stops the current communication. In communication, 
the network and the mobile station mutually notify enci- 
pherment-onset time and negotiate about encipherment 
manner with each other. In addition, diversity handover 
is commenced upon a call attempt. Furthermore, if a 



branch replacement is necessary, the current branch is 
replaced by new branches capable of executing the 
diversity handover. Additionally, when a new call occurs 
to or from the mobile station capable of treating a plural- 
ity of calls simultaneously, the mobile station uses the 
same branch structure and the same communication 
frequency band for all of calls. Additionally, when a new 
call occurs to or from the mobile station capable of treat- 
ing a plurality of calls simultaneously, a branch structure 
and a communication frequency band, which can con- 
tinue ail of the calls, are selected and used. Therefore, 
the mobile communications system is suitable for trans- 
mission of various sorts of data in accordance with the 
development of multimedia. 
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Description 



TECHNICAL FIELD 



5 [0001] The present invention generally relates to a method and system for mobile communication and especially 
relates to a method and system adopted to transmission of various sorts of data in accordance with the development 
of multimedia. 

BACKGROUND ART 

10 

[0002] Conventionally, portable telephones have been widely spread, and TDMA (time division multiple access) and 
FDMA (frequency division multiple access) were used for access methods for portable telephones. In these days, 
CDMA (code division multiple access) is being adopted instead of TDMA and FDMA because of various merits, such 
as high efficiency at usage of frequency band, facility of change of transmission rate, and preservation from eavesdrop- 
15 ping. 

[0003] However, CDMA according to prior art is prepared mainly for voice transmission and therefore is not suitable 
for data communication. In recent years, as the development of multimedia, not only voice but also various kinds of data 
that can be processed in computers and so on should be transmitted. Therefore, communication access between 
mobile stations and network should be suitable for transmitting various types of data in the near future. 

20 

DISCLOSURE OF INVENTION 

[0004] It is therefore an object of the present invention to provide a method and system for mobile communication 
suitable for transmitting various types of data in accordance with the development of multimedia. 

25 [0005] The present invention provides a method for mobile communication carried out among a plurality of mobile 
stations and a network, personal identifiers being previously and respectively assigned to the mobile stations, the 
method comprising the steps of: assigning temporary identifiers respectively to mobile stations which are communica- 
ble with the network; storing the personal identifiers and the temporary identifiers of the mobile stations by the network; 
storing the personal identifier and the temporary identifier of each mobile station by the mobile station; detecting by the 

30 network that one of the temporary identifiers stored in itself is different from that stored in the corresponding mobile sta- 
tion; and reassigning by the network another temporary identifier to the mobile station of which the former temporary 
identifier stored in the network is detected to be different from that stored in the corresponding mobile station. 
[0006] By virtue of the above invention, it is possible to provide a method and system for CDMA wireless communi- 
cation suitable for transmitting various types of data in accordance with the development of multimedia. 

35 [0007] The present invention provides a base station controller communicating with a mobile station, which is able to 
conduct diversity reception, via a plurality of radio base stations under control of a switching center, the controller com- 
prising enciphering means for enciphering transmitted information, which has been received from the switching center 
and should be transmitted to the mobile station, so as to generate enciphered transmitted information. 
[0008] In addition, the present invention provides a base station controller communicating with a mobile station, which 

40 is able to conduct diversity reception, via a plurality of radio base stations under control of a switching center, the con- 
troller comprising: retransmission-control-information-adding means for adding retransmission control information to 
enciphered transmitted information which has been previously enciphered by the switching center; and transmitting 
means for transmitting the enciphered transmitted information with the retransmission control information to the radio 
base stations. 

45 [0009] Additionally, the present invention provides a switching center communicating with a mobile station, which is 
able to conduct diversity reception, via a plurality of radio base stations and a base station controller, the switching 
center comprising enciphering means for enciphering transmitted information, which should be transmitted to the 
mobile station, so as to generate enciphered transmitted information. 

[001 0] In addition, the present invention provides a system for mobile communication including a mobile station which 
so is able to conduct diversity reception, a plurality of radio base stations, and a base station controller communicating via 
the radio base stations under control of a switching center, the system being characterized in that the base station con- 
troller enciphers information, which should be transmitted from the side of the switching center to the side of the mobile 
station, before distributing the information to the radio base stations. 

[0011] Additionally, the present invention provides a system for mobile communication including a mobile station 
55 which is able to conduct diversity reception, a plurality of radio base stations, and a base station controller communicat- 
ing via the radio base stations under control of a switching center, the system being characterized in that the switching 
center enciphers information, which should be transmitted from the side of the switching center to the side of the mobile 
station, before distributing the information to the radio base stations. 
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[001 2] In addition, the present invention provides a system for mobile communication including a mobile station which 
is able to conduct diversity reception, a plurality of radio base stations, and a base station controller communicating via 
the radio base stations under control of a switching center, the system comprising layer-2-enciphering-means for enci- 
phering information that should be processed only in one or more layers which are the same as or higher than layer 2 

5 of the OS I reference model. 

[0013] Additionally, the present invention provides a system for mobile communication including a mobile station 
which is able to conduct diversity reception, a plurality of radio base stations, and a base station controller communicat- 
ing via the radio base stations under control of a switching center, the system comprising: layer-3-enciphering-means 
for enciphering information that should be processed only in one or more layers which are the same as or higher than 

10 layer 3 of the OSI reference model; and layer-2-mutual-notifying-means for facilitating notification between layers of dif- 
ferent devices corresponding to layer 2 of the OSI reference model about an onset of transmission of enciphered infor- 
mation. 

[0014] Furthermore, the present invention provides a system for mobile communication including a mobile station 
which is able to conduct diversity reception, a plurality of radio base stations, and a base station controller communicat- 

75 ing via the radio base stations under control of a switching center, the system comprising: layer-3-enciphering-means 
for enciphering information that should be processed only in one or more layers which are the same as or higher than 
layer 3 of the OSI reference model; retransmission-control-information-adding means, at a layer corresponding to layer 
2 of the OSI reference model, for adding retransmission control information to information which has been previously 
enciphered by the layer-3-enciphering means; and transmitting means for transmitting the enciphered transmitted infor- 

20 mation with the retransmission control information to the radio base stations. 

[0015] In addition, the present invention provides a method for controlling a base station controller communicating 
with a mobile station, which is able to conduct diversity reception, via a plurality of radio base stations under control of 
a switching center, the system for mobile communication comprising the step of enciphering transmitted information, 
which has been received from the switching center and should be transmitted to the mobile station, so as to generate 

25 enciphered transmitted information. 

[0016] Furthermore, the present invention provides a method for controlling a base station controller communicating 
with a mobile station, which is able to conduct diversity reception, via a plurality of radio base stations under control of 
a switching center, the method comprising the steps of: adding retransmission control information to enciphered trans- 
mitted information which has been previously enciphered by the switching center; and transmitting the enciphered 

30 transmitted information with the retransmission control information to the radio base stations. 

[0017] Furthermore, the present invention provides a method for controlling a switching center communicating with a 
mobile station, which is able to conduct diversity reception, via a plurality of radio base stations and a base station con- 
troller, the method comprising the step of enciphering transmitted information, which should be transmitted to the 
mobile station, so as to generate enciphered transmitted information. 

35 [0018] Additionally, the present invention provides a method for controlling a system for mobile communication includ- 
ing a mobile station which is able to conduct diversity reception, a plurality of radio base stations, and a base station 
controller communicating via the radio base stations under control of a switching center, the method comprising the 
step of, at the base station controller, enciphering information, which should be transmitted from the side of the switch- 
ing center to the side of the mobile station, before transmitting the information to the base station controller. 

40 [0019] Furthermore, the present invention provides a method for controlling a system for mobile communication 
including a mobile station which is able to conduct diversity reception, a plurality of radio base stations, and a base sta- 
tion controller communicating via the radio base stations under control of a switching center, the method comprising the 
step of, at the switching center, enciphering information, which should be transmitted from the side of the switching 
center to the side of the mobile station, before distributing the information to the radio base stations. 

45 [0020] In addition, the present invention provides a method for controlling a system for mobile communication includ- 
ing a mobile station which is able to conduct diversity reception, a plurality of radio base stations, and a base station 
controller communicating via the radio base stations under control of a switching center, the method comprising the 
step of enciphering information that should be processed only in one or more layers which are the same as or higher 
than layer 2 of the OSI reference model. 

so [0021 ] Additionally, the present invention provides a method for controlling a system for mobile communication includ- 
ing a mobile station which is able to conduct diversity reception, a plurality of radio base stations, and a base station 
controller communicating via the radio base stations under control of a switching center, the method comprising the 
steps of: enciphering information that should be processed only in one or more layers which are the same as or higher 
than layer 3 of the OSI reference model; and facilitating notification between layers of different devices corresponding 

55 to layer 2 of the OSI reference model about an onset of transmission of enciphered information. 

[0022] The present invention provides a method for controlling a system for mobile communication including a mobile 
station which is able to conduct diversity reception, a plurality of radio base stations, and a base station controller com- 
municating via the radio base stations under control of a switching center, the method comprising the steps of: enci- 
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phering information that should be processed only in one or more layers which are the same as or higher than layer 3 
of the OSI reference model; adding retransmission control information at a layer corresponding to layer 2 of the OSI ref- 
erence model to information which has been previously enciphered by the enciphering step; and transmitting the enci- 
phered transmitted information with the retransmission control information to the radio base stations. 
5 [0023] By virtue of the invention as described above, it is possible for a mobile station to conduct diversity reception 
although the mobile station cannot simultaneously process enciphered transmission signal and non-enciphered trans- 
mission signal. 

[0024] In addition, the present invention provides a mobile station communicating with a network over the air, com- 
prising decipherment-onset-time-setting-means for setting a time to start deciphering an enciphered reception signal 
10 dependency on a time to start enciphering a transmission signal in the network and independently of a time to start 
enciphering a transmission signal in the mobile station. 

[0025] Furthermore, the present invention provides a mobile station further comprising deciphering means for deci- 
phering an enciphered reception signal received from the network over the air, the decipherment-onset-time-setting- 
means including encipherment-onset-request-determining means for determining if a reception encipherment onset 
15 request is received from the network or not; and decipherment-instructing means for instructing the deciphering means 
to start deciphering in accordance with a time when the reception encipherment onset request has been received on 
the basis of the determination. 

[0026] Additionally, the present invention provides a mobile station communicating with a network over the air, com- 
prising encipherment-onset-time-setting-means for setting a time to start enciphering a transmission signal independ- 

20 ently of a time to start deciphering an enciphered reception signal. 

[0027] Furthermore, the present invention provides a mobile station further comprising transmission-encipherment- 
onset-requesting means for transmitting a transmission encipherment onset request to the network over the air; and 
enciphering means for enciphering the transmission signal so as to generate an enciphered transmission signal, the 
encipherment-onset-time-setting-means including encipherment-instructing means for instructing the enciphering 

25 means to start enciphering in accordance with a time when the transmission encipherment onset request has been 
transmitted. 

[0028] In addition, the present invention provides a controller in a network communicating with a mobile station over 
the air, comprising decipherment-onset-time-setting-means for setting a time to start deciphering an enciphered recep- 
tion signal dependency on a time to start enciphering a transmission signal in the mobile station and independently of 

30 a time to start enciphering a transmission signal in the controller. 

[0029] Furthermore, the present invention provides a controller in a network further comprising deciphering means 
for deciphering an enciphered reception signal received from the mobile station over the air, the decipherment-onset- 
time-setting-means including encipherment-onset-request-determining means for determining if a reception encipher- 
ment onset request is received from the network or not; and decipherment-instructing means for instructing the deci- 

35 phering means to start deciphering in accordance with a time when the reception encipherment onset request has been 
received on the basis of the determination. 

[0030] The present invention provides a controller in a network communicating with a mobile station over the air, com- 
prising encipherment-onset-time-setting-means for setting a time to start enciphering a transmission signal independ- 
ently of a time to start deciphering an enciphered reception signal. 

40 [0031 ] Furthermore, the present invention provides a controller in a network further comprising transmission-enci- 
pherment-onset-requesting means for transmitting a transmission encipherment onset request to the mobile station 
over the air; and enciphering means for enciphering the transmission signal so as to generate an enciphered transmis- 
sion signal, the encipherment-onset-time-setting-means including encipherment-instructing means for instructing the 
enciphering means to start enciphering in accordance with a time when the transmission encipherment onset request 

45 has been transmitted. 

[0032] Additionally, the present invention provides a system for mobile communication comprising a mobile station 
and a network communicating with each other over the air, 

the network comprising: encipherment-onset-requesting means for transmitting an encipherment onset request to 
so the mobile station over the air; first-enciphered-transmission-signal-generating means for enciphering a first trans- 
mission signal which should be transmitted from the network to the mobile station after the transmission of the enci- 
pherment onset request, thereby generating a first enciphered transmission signal; first-enciphered-transmission- 
signal-transmitting means for transmitting the first enciphered transmission signal to the mobile station; response 
determining means for determining if an encipher onset response by the mobile station indicating that the encipher- 
55 ment onset request is acceptable is received or not; and first deciphering means for starting to decipher a second 
enciphered transmission signal from the mobile station on the basis of the determination of the response determin- 
ing means when the mobile station accepts the encipherment onset request, 

the mobile station comprising: request determining means for determining if the encipherment onset request is 



5 



V 



EP 0 978 958 A1 

f. 

received or not; encipherment-onset-responding means for transmitting the encipherment onset response on the 
basis of the determination of the request determining means when the encipherment onset request is accepted; 
second deciphering means for starting to decipher the first enciphered transmission signal from the network when 
the encipherment onset request is accepted; second-enaphered-transmission-signal-generating means for enci- 
5 phering a second transmission signal which should be transmitted from the mobile station to the network after the 
transmission of the encipherment onset response, thereby generating a second enciphered transmission signal; 
and second-enciphered-transmission-signal-transmitting means for transmitting the second enciphered transmis- 
sion signal to the network. 

10 [0033] In addition, the present invention provides a method for controlling a mobile station communicating with a net- 
work over the air, comprising the step of setting a time to start deciphering an enciphered reception signal dependency 
on a time to start enciphering a transmission signal in the network and independently of a time to start enciphering a 
transmission signal in the mobile station. 

[0034] Furthermore, the present invention provides a method for controlling a mobile station, further comprising the 
75 step of deciphering an enciphered reception signal received from the network over the air, the step of setting a time to 
start deciphering including the steps of determining if a reception encipherment onset request is received from the net- 
work or not; and instructing to start the deciphering step in accordance with a time when the reception encipherment 
onset request has been received on the basis of the determination. 

[0035] Additionally, the present invention provides a method for controlling a mobile station communicating with a net- 
20 work over the air, comprising the step of setting a time to start enciphering a transmission signal independently of a time 
to start deciphering an enciphered reception signal. 

[0036] Furthermore, the present invention provides a method for controlling a mobile station, further comprising the 
steps of transmitting a transmission encipherment onset request to the network over the air; and enciphering the trans- 
mission signal so as to generate an enciphered transmission signal, the step of setting a time to start enciphering 
25 including the step of instructing to start the enciphering step in accordance with a time when the transmission encipher- 
ment onset request has been transmitted. 

[0037] In addition, the present invention provides a method for controlling a controller in a network communicating 
with a mobile station over the air, comprising the step of setting a time to start deciphering an enciphered reception sig- 
nal dependency on a time to start enciphering a transmission signal in the mobile station and independently of a time 

30 to start enciphering a transmission signal in the controller. 

[0038] Furthermore, the present invention provides a method for controlling a controller in a network further compris- 
ing the step of deciphering an enciphered reception signal received from the mobile station over the air, the step of set- 
ting a time to start deciphering including the steps of determining if a reception encipherment onset request is received 
from the network or not; and instructing to start the deciphering step in accordance with a time when the reception enci- 

35 pherment onset request has been received on the basis of the determination. 

[0039] Additionally, the present invention provides a method for controlling a controller in a network communicating 
with a mobile station over the air, comprising the step of setting a time to start enciphering a transmission signal inde- 
pendently of a time to start deciphering an enciphered reception signal. 

[0040] Furthermore, the present invention provides a method for controlling a controller in a network further compris- 
40 ing the steps of transmitting a transmission encipherment onset request to the mobile station over the air; and encipher- 
ing the transmission signal so as to generate an enciphered transmission signal, the step of setting a time to start 
enciphering including the step of instructing to start the enciphering step in accordance with a time when the transmis- 
sion encipherment onset request has been transmitted. 

[0041 ] In addition, the present invention provides a method for controlling a system for mobile communication in which 
45 a mobile station and a network communicate with each other over the air, the method comprising the steps of: transmit- 
ting an encipherment onset request from the network to the mobile station over the air; enciphering a first transmission 
signal which should be transmitted from the network to the mobile station after the transmission of the encipherment 
onset request thereby generating a first enciphered transmission signal; transmitting the first enciphered transmission 
signal to the mobile station; determining if an encipher onset response by the mobile station indicating that the enci- 
so pherment onset request is acceptable is received or not; starting to decipher a second enciphered transmission signal 
from the mobile station on the basis of the determination of the response determining step when the mobile station 
accepts the encipherment onset request; determining if the encipherment onset request is received or not; transmitting 
the encipherment onset response on the basis of the determination of the request determining step when the encipher- 
ment onset request is accepted; starting to decipher the f irst enciphered transmission signal from the network when the 
55 encipherment onset request is accepted; enciphering a second transmission signal which should be transmitted from 
the mobile station to the network after the transmission of the encipherment onset response, thereby generating a sec- 
ond enciphered transmission signal; and transmitting the second enciphered transmission signal to the network. 
[0042] By virtue of the aspects of the invention as set forth, although the structural elements in the network are not 
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provided with the function to read both of enciphered and non-enciphered signals simultaneously as simplifying the sys- 
tem, the timing of the encipherment onset is aligned in the base station and the network, so that the communication 
between the mobile station and the network can be facilitated surely and smoothly. 

[0043] Additionally, the present invention provides a mobile station communicating with a network over the air, com- 
5 prising encipherment-procedure-notifying-means for notifying the network about encipherment-procedure-specifying- 
information specifying one or more possible encipherment procedures of the mobile station. 
[0044] Furthermore, the present invention provides a mobile station, wherein the entipherment-procedure-notifying- 
means further including enciphering-key-generation-procedure-notifying-means for notifying the network about enci- 
phering-key-generationiDrocedure-specifying-information specifying one or more possible enciphering key generation 
w procedures of the mobile station. 

[0045] In addition, the present invention provides a mobile station communicating with a network over the air, com- 
prising encipherment communication means for conducting an encipherment procedure corresponding to an encipher- 
ment request given by the network and for communicating with the network. 

[0046] Furthermore, the present invention provides a mobile station, wherein the encipherment communication 
is means includes enciphering-key-generating-means for generating an enciphering key corresponding to enciphering- 
key-generation-procedure-specifying-means specifying an enciphering key generation procedure notified by the net- 
work; and enciphering means for conducting an encipherment procedure using the enciphering key generated by the 
enciphering-key-generating-means. 

[0047] Additionally, the present invention provides a controller in a network communicating with a mobile station over 

20 the air, comprising encipherment-procedure-selecting means for selecting an encipherment procedure for communica- 
tion in accordance with encipher ment-procedure-specifying-information, specifying one or more possible encipherment 
procedures of the mobile station, notified by the mobile station; and encipherment requesting means for notifying the 
mobile station about an encipherment request requesting the mobile station to conduct an encipherment using the enci- 
pherment procedure selected by the encipherment-procedure-selecting means. 

25 [0048] Furthermore, the present invention provides a controller in a network further comprising enciphering-key-gen- 
eration-procedure-selecting-means for selecting an enciphering key generation procedure in accordance with encipher- 
ing-key-generation-procedure-specrfying-information, specifying one or more possible encipherment procedures of the 
mobile station, notified by the mobile station; and enciphering-key-notifying means for notifying the base station about 
the enciphering key generation procedure selected by the enciphering-key-generation-procedure-selecting-means. 

30 [0049] By virtue of the aspects of the invention as set forth, it is possible to select the encipherment procedure 
adapted to the security level instructed by the mobile station or the mobile station user, thereby conducting the enci- 
pherment procedure. It is also possible select the encipherment procedure adapted to the multimedia service for trans- 
porting voice or moving picture from the mobile station or the network, thereby conducting the encipherment procedure. 
Furthermore, if it is necessary to enhance the security level for future extension of communication systems and for 

35 newly executed services, it will be possible to readily introduce a newly developed encipherment procedure. In addition, 
if a plurality of networks are provided with the ability for conducting one or more common encipherment procedures, it 
is possible to conduct one of the encipherment procedures when the mobile station roams across the service areas of 
the networks although all of the possible encipherment procedures are not commonly shared. Even in this case, it is 
also possible in each network to conduct one or more original enciphermertt procedures. 

40 [0050] The present invention provides a method for controlling access links between a mobile station and a network, 
characterized in that a plurality of branches are established between the network and the mobile station upon a call 
attempt to or from the mobile station located at a position where the mobile station can communicate using diversity 
handover, the plurality of branches including a main branch and at least one auxiliary branch for additional use in order 
that the mobile station may communicate using diversity handover, thereby enabling the mobile station to commence 

45 the diversity handover using the plurality of branches. 

[0051] In addition, the present invention provides a mobile station characterized in that it establishes a plurality of 
branches between the network and the mobile station upon the reception of a message from the network when no 
access link is established between the network and the mobile station, the message including a request for establishing 
the branches, thereby commencing the diversity handover using the plurality of branches. 

so [0052] Additionally, the present invention provides a base station controller characterized in that it establishes a plu- 
rality of branches between a network and a mobile station upon a call attempt to or from the mobile station at a location 
where the mobile station can communicate using diversity handover, the plurality of branches including a main branch 
and at least one auxiliary branch .for additional use in order that the mobile station may communicate using diversity 
handover. 

55 [0053] In addition, the present invention provides a base station controller characterized in that it transmits a message 
to both of a base station and a mobile station upon a call attempt to or from the mobile station at a location where the 
mobile station can communicate by means of intra-cell diversity handover wherein the mobile station and the base sta- 
tion communicate with each other using a plurality of branches, the message including a request for establishing a plu- 
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rality of branches including a main branch and at least one auxiliary branch for additional use in order that the mobile 
station may communicate by means of intra-cel! diversity handover. 

[0054] Additionally, the present invention provides a base station controller characterized in that it transmits a mes- 
sage to a plurality of base stations upon a call attempt to or from the mobile station at a location where the mobile sta- 
5 tion can communicate by means of inter-cell diversit)"handover wherein the mobile station communicates with the 
plurality of base stations, the message including a request for establishing a plurality of branches between the mobile 
station and the corresponding base stations. 

[0055] In addition, the present invention provides a base station characterized in that it establishes a plurality of 
branches between the base station and the mobile station according to an instruction from abase station controller upon 

10 a call attempt to or from the mobile station at a location where the mobile station can communicate by means of intra- 
cell diversity handover wherein the mobile station and the base station communicate with each other using the plurality 
of branches, the plurality of branches including a main branch and at least one auxiliary branch for additional use in 
order that the mobile station may communicate by means of intra-cell diversity handover, thereby enabling the mobile 
station to commence the intra-cell diversity handover. 

15 [0056] By virtue of the aspects of the invention as set forth, when there is the mobile station at a location where it can 
communicate by means of intra-cell diversity handover wherein the mobile station and the base station communicate 
with each other using the plurality of branches, a series of procedures for establishing the main branch and for adding 
the auxiliary branch can be carried out upon the call attempt to or from the mobile station. Therefore, the number of sig- 
nal flows can be reduced, so that it is possible to transit diversity handover condition efficiently and to decrease the 

20 interference to other radio access links. 

[0057] The present invention provides a method for controlling a branch replacement characterized in that at least a 
current branch between a network and a mobile station are replaced with a plurality of branches necessary for commu- 
nication using diversity handover when the branch replacement is necessary for the mobile station and when it is rec- 
ognized that the mobile station can commence communicating using diversity handover if the branch replacement is 

25 carried out, thereby enabling the mobile station to commence diversity handover. 

[0058] Additionally, the present invention provides a mobile station characterized in that it replaces at least a current 
branch between a network and the mobile station with a plurality of branches necessary for communication using diver- 
sity handover when a branch replacement is necessary for the mobile station and when the mobile station can com- 
mence communicating using the diversity handover branches if the branch replacement is carried out, thereby 

30 commencing diversity handover. 

[0059] In addition, the present invention provides a base station controller characterized in that it replaces at least a 
current branch between a network and a mobile station with a plurality of branches necessary for communication using 
diversity handover when a branch replacement is necessary for the mobile station and when it is recognized that the 
mobile station can commence communicating using diversity handover if the branch replacement is carried out, thereby 

35 enabling the mobile station to commence diversity handover. 

[0060] Additionally, the present invention provides a base station controller characterized in that it transmits a mes- 
sage to a base station and a mobile station when a branch replacement is necessary for the mobile station and when 
it is recognized that, if the branch replacement is carried out, the mobile station can commence communicating by 
means of intra-cell diversity handover wherein the mobile station and the base station communicate with each other 

40 using a plurality of branches, the message including an instruction to carry out the branch replacement and an instruc- 
tion to add at least one auxiliary branch for additional use in order to communicate using diversity handover. 
[0061 ] In addition, the present invention provides a base station controller characterized in that it transmits an instruc- 
tion to a plurality of base stations and a message to a mobile station when a branch replacement is necessary for the 
mobile station and when it is recognized that the mobile station can commence communicating by means of inter-cell 

45 diversity handover if the branch replacement is carried out, the instruction instructing the base stations to set branches 
necessary for the diversity handover, the message including an instruction to carry out the branch replacement and an 
instruction to add at least one auxiliary branch for additional use in order to communicate using diversity handover. 
[0062] Additionally, the present invention provides a base station characterized in that it replaces a branch for a mobile 
station and adds at least one auxiliary branch for the mobile station according to instructions of a message once the 

so base station receives the message from a base station controller, the message including an instruction to carry out 
branch replacement and an instruction to add at least one auxiliary branch for additional use in order to communicate 
using diversity handover, thereby commencing the intra-cell diversity handover. 

[0063] The aspects of the invention as set forth replaces the current branch or branches with the branches adapted 
to diversity handover upon a trigger for the branch replacement when it is recognized that the diversity handover can be 
55 commenced if the branch replacement is conducted. Therefore, the number of signal flows can be reduced, so that it is 
possible to transit diversity handover condition efficiently and to decrease the interference to other radio access links. 
[0064] The present invention provides a branch controlling method for a mobile station capable of treating a plurality 
of calls simultaneously, characterized in that when a new call occurs while the mobile station treats an existent call, at 
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least either of branch structures for both of the calls or at least either of communication frequency bands for both of the 
calls is controlled, so that the branch structures are the same as each other and the communication frequency bands 
- are the same as each other. 

[0065] In addition, the present invention provides a branch controlling method for a mobile station capable of treating 
5 a plurality of calls simultaneously, characterized in that when a new call occurs while the mobile station treats an exist- 
ent call, a branch structure and a communication frequency band being the same as those for the existent call are 
assigned to the new call. 

[0066] Additionally, the present invention provides a mobile station capable of treating a plurality of calls simultane- 
ously, characterized in that when a new call occurs while the mobile station treats an existent call, the mobile station 

w uses a branch structure being the same as that for the existent call to the new call and a communication frequency band 
being the same as that for the existent call to the new call in accordance with an instruction from a network. 
[0067] In addition, the present invention provides a base station controller adapted for a mobile station capable of 
treating a plurality of calls simultaneously, characterized in that when a new call occurs while the mobile station treats 
an existent call, the base station controller controls at least either of branch structures for both of the calls or at least 

is either of communication frequency bands for both of the calls, so that the branch structures are the same as each other 
and the communication frequency bands are the same as each other. 

[0068] Additionally, the present invention provides a base station controller adapted for a mobile station capable of 
treating a plurality of calls simultaneously, characterized in that when a new call occurs while the mobile station treats 
an existent call, the base station controller assigns a branch structure and a communication frequency band being the 
20 same as that for the existent call to the new call. 

[0069] By virtue of the aspects of the invention as set forth, it is possible to assigns the same branch structure and 
the same frequency band for the plurality of calls including the existent and new calls, so as to ease the control for both 
of the calls. 

[0070] The present invention provides a branch controlling method adapted for a mobile station capable of treating a 

25 plurality of calls simultaneously, characterized in that when a new call occurs while the mobile station treats an existent 
call and when it is impossible to assign a branch structure or a communication frequency band, being the same as the 
branch structure or the communication frequency band for the existent call, to the new call, another branch structure or 
another communication frequency band which can continue both of the existent and new calls is selected, and the 
selected branch structure or communication frequency band is assigned to both of the existent and new calls. 

30 [0071 ] The present invention provides a mobile station capable of treating a plurality of calls simultaneously, charac- 
terized in that when a new call occurs while the mobile station treats an existent call and when it is impossible to assign 
a branch structure or a communication frequency band, being the same as the branch structure or the communication 
frequency band for the existent call, to the new call, the mobile station assigns another branch structure or another com- 
munication frequency band, which can continue both of the existent and new calls, to both of the existent and new calls 

35 in accordance with an instruction from a network 

[0072] The present invention provides a base station controller adapted for a mobile station capable of treating a plu- 
rality of calls simultaneously, characterized in that when a new call occurs while the mobile station treats an existent call 
and when it is impossible to assign a branch structure or a communication frequency band, being the same as the 
branch structure or the communication frequency band for the existent call, to the new call, the base station controller 

40 selects another branch structure or another communication frequency band which can continue both of the existent and 
new calls, and assigns the selected branch structure or communication frequency band to both of the existent and new 
calls. 

[0073] By virtue of the aspects of the invention as set forth, it is possible to assigns the same branch structure and 
the same frequency band for the plurality of calls including the existent and new calls, so as to ease the control for both 
45 of the calls. 

[0074] The present invention provides a branch controlling method adapted for a mobile station, characterized in that 
when a trigger of handover occurs to the mobile station which is treating a plurality of calls, a branch structure or a com- 
munication frequency band which can continue all of the calls is selected, and the selected branch structure or commu- 
nication frequency band are assigned to all of the calls commonly. 

so [0075] The present invention provides a mobile station capable of treating a plurality of calls simultaneously, charac- 
terized in that when a trigger of handover occurs to the mobile station which is treating a plurality of calls, the mobile 
station, according to an instruction from a network, alters a branch structure or a communication frequency band for all 
of the calls to a new branch structure or a new communication frequency band for all of the calls commonly. 
[0076] The present invention provides a base station controller adapted for a mobile station, characterized in that 

55 when a trigger of handover occurs to the mobile station which is treating a plurality of calls, the base station controller 
selects a branch structure or a communication frequency band which can continue ail of the calls, and assigns the 
selected branch structure or communication frequency band to all of the calls commonly. 

[0077] By virtue of the aspects of the invention as set forth, it is possible to assigns the same branch structure and 
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the same frequency band for the plurality of calls during communicating although handover is carried out. so as to ease 
* the control for all of the calls. 

[0078] The present invention provides a branch controlling method adapted for a mobile station, characterized in that 
when a trigger of handover occurs to the mobile station which is treating a plurality of calls and when there is not a 
5 branch structure which can continue all of the calls in relation to the mobile station or when there is not a communication 
frequency band which can continue all of the calls in relation to the mobile station, another branch structure or another 
communication frequency band which can continue a plurality of calls being high in priority among the calls are 
selected; the other call or calls are released; and the selected branch structure and communication frequency band are 
assigned to the priority calls. 

10 [0079] In addition, the present invention provides a mobile station characterized in that when a trigger of handover 
occurs to the mobile station which is treating a plurality of calls and when there is not a branch structure which can con- 
tinue all of the calls in relation to the mobile station or when there is not a communication frequency band which can 
continue all of the calls in relation to the mobile station, the mobile station, according to an instruction from a network, 
releases a call or calls being low in priority; and assigns a branch structure and a communication frequency band 

is selected by the network to a plurality of calls being high in priority. 

[0080] Additionally, the present invention provides a base station controller adapted for a mobile station, characterized 
' in that when a trigger of handover occurs to the mobile station which is treating a plurality of calls and when there is not 
a branch structure which can continue all of the calls in relation to the mobile station or there is not a communication 
frequency band which can continue all of the calls in relation to the mobile station, the base station controller selects 

20 another branch structure and another communication frequency band which can continue a plurality of calls being high 
in priority among the calls; releases the other call or calls; and assigns the selected branch structure and communica- 
tion frequency band to the priority calls. 

[0081] By virtue of the aspects of the invention as set forth, it is possible to continue the calls with a high priority when 
the trigger for handover occurs although there are not a branch structure and a communication frequency band which 
25 can continue all of the calls. In other words, it is possible to continue at least the calls with a high priority although there 
are not ample wireless communication resources. 

[0082] In addition, the present invention provides a method for establishing a control channel in a mobile communi- 
cation system wherein a mobile station treats a plurality of calls using a plurality of sets of wireless communication 
resources, characterized in that a single control channel is established between the mobile station and a network for 

30 transporting control information therebetween in a manner that the control channel is famed by one of the sets of wire- 
less communication resources which are being used for a plurality of calls by the mobile station. 
[0083] By virtue of the invention, it is possible to reduce the number of hardware elements for transporting control 
information in comparison with the case that all of the plurality of calls utilize control channels, respectively. In addition, 
it is possible to exclude complicated control procedures, e.g., management of the transportation order of control infor- 

35 mation in the plurality of control channels. 

[0084] Additionally, the present invention provides a method for controlling to replace a control channel, characterized 
in that while a mobile station treats a plurality of calls using a plurality of sets of wireless communication resources and 
transmits or receives control information to or from a network via a single control channel formed by one of the sets of 
the wireless communication resources, and when a first call using the control channel formed by one of the sets of the 

40 wireless communication resources should be released and a second call should be continued, the control channel, 
which is formed by one of the sets of the wireless communication resources and should be released, is replaced with a 
new control channel formed by another set of the wireless communication resources, thereby continuing to control the 
second call. 

[0085] In addition, the present invention provides a base station controller, characterized in that while a mobile station 
45 treats a plurality of calls using a plurality of sets of wireless communication resources and transmits or receives control 
information to or from a network via a control channel formed by one of the sets of the wireless communication 
resources, and when a first call using the control channel formed by one of the sets of the wireless communication 
resources should be released and a second call should be continued, the controller replaces the control channel, which 
is formed by one of the sets of the wireless communication resources and should be released, to a new control channel 
so formed by another set of the wireless communication resources, thereby continuing to control the second call. 

[0086] By virtue of the aspects of the invention as set forth, while a mobile station transmits or receives control infor- 
mation with respect to a plurality of calls via a common control channel, and when a first call using the control channel 
formed by one of the sets of the wireless communication resources should be released and a second call should be 
continued by means of another set of the wireless communication resources, the control channel is replaced. Accord- 
55 ingly, after the replacement, by means of the new control channel, it is possible to continue the transportation of control 
signal for the second call. 

[0087] The present invention provides a method for determining a radio zone and an uplink transmission power, char- 
acterized in that 



10 



EP0 978 958 A1 



each of base stations transmits broadcast information indicating a perch channel transmission power level and an 
uplink interference level via a corresponding perch channel; and 

a mobile station receives the broadcast information from near base stations around the mobile station; 
detects respective reception levels of the perch channels for the near base stations; 
5 calculates respective path losses between the mobile station and respective near base stations on the basis of the 
respective reception levels and the respective perch channel transmission power levels within the broadcast infor- 
mation; 

calculates respective necessary uplink transmission power levels between the mobile station and respective near 
base stations on the basis of the calculated respective path losses, the respective uplink interference levels within 

10 the broadcast information, and required signal-to-interference ratios involved in reception by the near base stations; 
selects a radio zone in which the necessary uplink transmission power level is minimum among the respective nec- 
essary uplink transmission power levels, the base station of the selected radio zone being ready for communication 
with the mobile station or being able to commence communication with the mobile station after handover; and 
controls an uplink transmission power in the selected radio zone based on the necessary uplink transmission power 

15 level of the selected radio zone. 

[0088] Additionally, the present invention provides a base station comprising means for transmitting broadcast infor- 
mation indicating a perch channel transmission power level and an uplink interference level via a perch channel. 
[0089] In addition, the present invention provides a mobile station characterized in that it 

20 

receives broadcast information from near base stations around the mobile station via respective perch channels, 
the broadcast information from each of the near base stations indicating a perch channel transmission power level 
and an uplink interference level; 

detects respective reception levels of the perch channels for the near base stations; 
25 calculates respective path losses between the mobile station and respective near base stations on the basis of the 
respective reception levels and the respective perch channel transmission power levels within the broadcast infor- 
mation; 

calculates respective necessary uplink transmission power levels between the mobile station and respective near 
base stations on the basis of the calculated respective path losses, the respective uplink interference levels within 

30 the broadcast information, and required signal-to-interference ratios involved in reception by the near base stations; 
selects a radio zone of which the necessary uplink transmission power level is minimum among the respective nec- 
essary uplink transmission power levels, the base station of the selected radio zone being ready for communication 
with the mobile station or being able to commence communication with the mobile station after handover; and 
controls an uplink transmission power in the selected radio zone based on the necessary uplink transmission power 

35 level of the selected radio zone. 

[0090] By virtue of the aspects of the invention as set forth, although perch channel transmission power levels for 
respective base stations are different from each other or one another, it is possible to optimize the uplink transmission 
power of the mobile station. 

40 [0091 ] The present invention provides a handover controlling method for additionally establishing a handover branch 
between a mobile station and a network, characterized in that a procedure for additional establishment of a branch is 
completed with a state transition to which the mobile station can commence communicating without waiting for a con- 
firmation of synchronization for ail branches. 

[0092] The present invention provides a handover controlling method further characterized in that the procedure for 
45 additional branch establishment is completed with confirmation of synchronization for one branch among the branches 
established for the mobile station. 

[0093] Additionally, the present invention provides a mobile station characterized in that if the mobile station has 
received a request from a network to establish a new additional branch between the network and the mobile station, the 
mobile station establishes the new branch and then starts diversity reception upon reception of a signal through the new 
so branch. 

[0094] In addition, the present invention provides a base station characterized in that if the base station has received 
a request from a base station controller to establish a new additional branch between a mobile station and the base sta- 
tion for carrying out intra-cell diversity handover, the base station additionally establishes the new branch and then 
starts intra-cell diversity reception upon reception of a signal through the new branch. 
55 [0095] Additionally, the present invention provides a base station characterized in that if the base station has received 
a request from a base station controller to establish a new additional branch between a mobile station and the base sta- 
tion for carrying out inter-cell diversity handover, the base station establishes the new branch and then starts sending 
the received signals to the base station controller that executes inter-cell diversity reception upon reception of a signal 
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through the new branch. 

[0096] In addition, the present invention provides a base station controller characterized in that when the base station 
controller establishes a new additional branch between a mobile station and a network, the base station controller pro- 
vides a request for establishing the new branch and then completes a procedure for additional establishment of the new 
5 branch without waiting for a confirmation of synchronization for all branches between the mobile station and the net- 
work. 

[0097] Furthermore, the present invention provides a base station controller further characterized in that it provides 
the request for establishing the new branch being necessary for inter-cell diversity handover, and then starts inter-cell 
. diversity reception upon reception of signals through the branches being necessary for inter-cell diversity handover. 
10 [0098] By virtue of the aspects of the invention as set forth, since the procedure for additional establishment of the 
new branch is completed when the mobile station can communicate, the additional establishment procedure can be 
ended in a short time period. 

[0099] The present invention provides a radio mobile communication system wherein a plurality of channels can be 
established on a single carder frequency by code division multiplex access, characterized in that the system comprises 
15 code-resource-assigning means for assigning at least a part of an assignable code resource to one of the channels in 
accordance with a transmission rate necessary for the corresponding channel, the part corresponding to a certain 
bandwidth corresponding to the transmission rate. 

[01 00] Furthermore, the present invention provides a radio mobile communication system further comprising channel- 
assigning means for assigning one of the channels, to which a part of the assignable code resource is assigned, to a 

20 mobile station in accordance with a transmission rate necessary for the mobile station. 

[0101 ] Additionally, the present invention provides a radio mobile communication system wherein a plurality of chan- 
nels can be established on a single carrier frequency by code division multiplex access, characterized in that the system 
comprises a plurality of assignable code resources, each of code resources corresponding to a certain bandwidth and 
being independent of the other code resources; and reassigning means for reassigning a part of an assignable code 

25 resource to one of the channels to which a part of another assignable code resource is already assigned if there is not 
an unused code resource corresponding to a bandwidth suitable for a necessary transmission rate when assigning an 
unused assignable code resource to one of the channels in accordance with the necessary transmission rate. 
[0102] Additionally, the present invention provides a radio mobile communication system further comprising unused- 
code-resource determining means for determining if there is an unused code resource corresponding to a bandwidth 

30 suitable for a necessary transmission rate or not when assigning an unused assignable code resource to one of the 
channels in accordance with the necessary transmission rate necessary. 

[0103] Furthermore, the present invention provides a radio mobile communication system according to claim 91, 
wherein at least one standard code resource corresponding to a predetermined bandwidth is preselected and the sys- 
tem comprises assignment-possibility-determining means for determining at predetermined moments if there is at least 
35 one unused standard code resource or not, the reassigning means reassigning a part of an assignable code resource 
to one of the channels to which apart of another assignable code resource is already assigned until an unused standard 
code resource is reserved if the determination result by the assignment-possibiiity-determining means has been nega- 
tive. 

[01 04] In addition, the present invention provides a radio base station for which a plurality of channels can be estab- 
40 lished on a single carrier frequency by code division multiplex access, characterized in that it comprises code-resource- 
assignment-possibility-determining means for determining whether or not it is possible to assign at least a part of an 
assignable code resource to one of channels in accordance with a transmission rate necessary for the corresponding 
channel, the part corresponding to a certain bandwidth corresponding to the transmission rate. 
[0105] The present invention provides a base station controller further comprising channel-assigning means for 
45 assigning a channel, to which a part of assignable code resource is assigned, to a mobile station in accordance with a 
transmission rate necessary for the mobile station. 

[0106] Additionally, the present invention provides a method for controlling a radio mobile communication system 
wherein a plurality of channels can be established on a single carrier frequency by code division multiplex access, char- 
acterized in that the method comprises code-resource-assigning step for assigning at least a part of an assignable code 
so resource to one of the channels in accordance with a transmission rate necessary for the corresponding channel, the 
part corresponding to a certain bandwidth corresponding to the transmission rate. 

[0107] In addition, the present invention provides a method for controlling a radio mobile communication system 
including a plurality of assignable code resources, each of code resources corresponding to a certain bandwidth and 
being independent of the other code resources, a plurality of channels being capable ofbeing established on a single 
55 carrier frequency by code division multiplex access, characterized in that in order to assign an unused assignable code 
resource to one of the channels in accordance with a necessary transmission rate, the method comprises the steps of 
determining whether or not there is an unused code resource having a code resource length in accordance with the 
necessary transmission rate; and reassigning a part of an assignable code resource to one of the channels to which a 
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part of another assignable code resource is already assigned if the determination indicates that there is not an unused 
code resource having a bandwidth suitable for the necessary transmission rate. 

[0108] Additionally, the present invention provides a method for controlling radio base station for which a plurality of 
channels can be established on a single carrier frequency by code division multiplex access, characterized in that it 
5 comprises a code-resource-assignment-possibility-determining step for determining whether or not it is possible to 
assign at least a part of an assignable code resource to one of channels in accordance with a transmission rate neces- 
sary for the corresponding channel, the part corresponding to a certain bandwidth corresponding to the transmission 
rate. 

[0109] In addition, the present invention provides a method for controlling a radio base station comprising a channel- 
10 assigning step for assigning a channel, to which a part of an assignable code resource is assigned to a mobile station 
in accordance with a transmission rate necessary for the mobile station. 

[01 1 0] By virtue of the aspects of the invention as set forth, it is possible to minimize the number of reassignments or 
rearrangements of code resources for channels, and call generations do not involve the rearrangement of code 
resource. Therefore, it is possible to reduce connection time delay. 

15 

BRIEF DESCRIPTION OF DRAWINGS 
[0111] 

20 Figure 1 is a block diagram showing the entire structure of a mobile communications system in accordance with W- 
CDMA of one embodiment of the present invention. 

Figure 2 is a block diagram showing a part of the system, particularly showing access interfaces in the system. 
Figure 3 is a diagram showing the functional network architecture of the system, in which functional entities are 
arranged in a communication control plane and a radio resource control plane. 
25 Figure 4 is a diagram showing the functional network architecture of the system, in which functional entities are 
arranged in a communication control plane and a radio resource control plane. 

Figure 5 is a diagram showing the functional model of a part of the invented system for describing an origination for 
initial call. 

Figure 6 is a diagram showing the functional model of a part of the invented system for describing an origination for 
30 additional call. 

Figures 7 and 8 form an information flow diagram showing the origination for initial call. 
Figure 9 is an information flow diagram showing the origination for additional call. 

Figure 10 is a diagram showing the functional model of a part of the invented system for describing acceptance of 
initial incoming call. 

35 Figure 1 1 is a diagram showing the functional model of a part of the invented system for describing acceptance of 
additional incoming call. 

Figures 12 through 14 form an information flow diagram showing the acceptance of initial incoming call. 
Figures 15 and 16 form an information flow diagram showing the acceptance of additional incoming call. 
Figure 1 7 is a diagram showing the functional model of a part of the invented system for describing a disconnection 
40 instructed by a user. 

Figure 18 is an information flow diagram showing the disconnection instructed by a user. 

Figure 19 is a diagram showing the functional model of a part of the invented system for describing a disconnection 

instructed by the network. 

Figure 20 is an information flow diagram showing the disconnection instructed by the network. 
45 Figure 21 is a diagram showing the functional model of a part of the invented system for describing an abnormal 
release caused from a radio link failure detected by a mobile terminal. 

Figure 22 is an information flow diagram of the abnormal release caused from the radio link failure detected by the 
mobile terminal. 

Figure 23 is a diagram showing the functional model of a part of the invented system for describing an abnormal 
so release caused from a radio link failure detected by the network. 

Figure 24 is an information flow diagram of the abnormal release caused from the radio link failure detected by the 
network. 

Figure 25 is a diagram showing the functional model of a part of the invented system for describing a user discon- 
nect. 

55 Figure 26 is an information flow diagram of the user disconnect. 

Figure 27 is a diagram showing the functional model of a part of the invented system for describing an SDCCH 
setup process. 

Figure 28 is an information flow diagram of the SDCCH setup process. 
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Figure 29 is a diagram showing the functional model of a part of the invented system for describing a bearer setup 
for the radio resource selection. 

Figure 30 is an information flow diagram of the bearer setup, executed in the communication control plane, for the 
radio resource selection. 

5 Figure 31 is a diagram showing the functional model of a part of the invented system for describing a radio bearer 
release. 

Figure 32 is an information flow diagram of the radio bearer release. 

Figure 33 is a diagram showing the functional model of a part of the invented system for describing an SDCCH 
release. 

w Figure 34 is an information flow diagram of the SDCCH release. 
Figure 35 is a flow chart showing handover processes in general. 
Figure 36 is an information flow diagram showing processes 1 and 2 described above. 

Figure 37 is an information flow diagram representing a sequence in which information flows are transported for 

starting non-soft handover execution, the sequence corresponding to process 1 in Figure 35. 
15 Figure 38 is an information flow diagram representing a sequence in which information flows are transported for 

starting handover branch addition, the sequence corresponding to process 1 in Figure 35. 

Figure 39 is an information flow diagram representing a sequence in which information flows are transported for 

starting handover branch deletion, the sequence corresponding to process 1 in Figure 35. 

Figure 40 is a diagram showing the functional model of a part of the invented system for describing an inter-sector 
20 handover branch addition in a single cell. 

Figure 41 is an information flow diagram of the inter-sector handover branch addition in a single cell, executed in 

the communication control plane. 

Figure 42 is a diagram showing the functional model of a part of the invented system for describing an inter-cell 
handover branch addition. 

25 Figure 43 is an information flow diagram of the inter-cell handover branch addition, executed in the communication 
control plane. 

Figure 44 is a diagram showing the functional model of a part of the invented system for describing an inter-sector 
handover branch deletion in a single cell. 

Figure 45 is an information flow diagram of the inter-sector handover branch deletion in a single cell, executed in 
30 the communication control plane. 

Figure 46 is a diagram showing the functional model of a part of the invented system for describing an inter-cell 
handover branch deletion. 

Figure 47 is an information flow diagram of the inter-cell handover branch deletion, executed in the communication 
control plane. 

35 Figure 48 is a diagram showing the functional model of a part of the invented system for describing an intra-cell 
branch replacement handover. 

Figure 49 is an information flow diagram of the intra-cell branch replacement handover executed in the communi- 
cation control plane. 

Figure 50 is a diagram showing the functional model of a part of the invented system for describing an inter-cell 
40 branch replacement handover. 

Figure 51 is an information flow diagram of the inter-cell branch replacement handover executed in the communi- 
cation control plane. 

Figure 52 is a diagram showing the functional model of a part of the invented system for describing an ACCH 
replacement procedure. 

45 Figures 53 and 54 cooperate to form an information flow diagram of the ACCH replacement procedure executed in 
the communication control plane. 

Figure 55 is a diagram showing the functional model of a part of the invented system for describing a code replace- 
ment. 

Figure 56 is an information flow diagram of the code replacement procedure executed in the communication control 
so plane. 

Figure 57 is a diagram showing the functional model of a part of the invented system for describing a transmission 
power control. Figure 58 is an information flow diagram of the transmission power control executed in the commu- 
nication control plane. 

Figure 59 is a diagram showing the functional model of a part of the invented system for descibing a terminal ioca- 
55 tion updating. 

Figures 60 and 61 form an information flow diagram of the terminal location updating. 

Figure 62 is a diagram showing the functional model of a part of the invented system for describing a user authen- 
tication. 
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Figure 63 is an information flow diagram representing the user authentication procedure in the invented system. 
Figure 64 is a diagram showing functional entities in the invented system for describing an encipherment onset time 
notification. 

Figure 65 is an information flow diagram representing the encipherment onset time notification. 
5 Figure 66 is a diagram showing functional entities in the invented system for describing a TMUI assignment. 
Figure 67 is an information flow diagram representing the TMUI assignment. 
Figure 68 is an information flow diagram representing a user ID retrieval. 

Figure 69 is a diagram representing the correlation between physical node configuration and functional entities in 
the invented system. 

10 Figure 70 is a diagram representing the signaling layer 2 protocol architecture over the radio interface. 
Figure 71 is a diagram representing a sample frame structure for the BSC function termination. 
Figure 72 is a diagram representing the format of a sequenced data PDU (SD PDU). 

Figure 73 is a diagram representing the format of a sequenced<lata-with-status-request PDU (SD-with-POLL 
PDU). 

15 Figure 74 is a diagram representing the format of a POLL PDU. 

Figure 75 is a diagram representing the format of a STAT PDU. 

Figure 76 is a diagram representing the format of a USTAT PDU. 

Figure 77 is a diagram representing the format of a UD PDU and a MD PDU. 

Figure 78 is a diagram representing the format of a Begin PDU (BGN PDU). 
20 Figure 79 is a diagram representing the format of a BGAK PDU. 

Figure 80 is a diagram representing the format of a BGREJ PDU. 

Figure 81 is a diagram representing the format of an END PDU. 

Figure 82 is a diagram representing the format of an ENDAK PDU. 

Figure 83 is a diagram representing the format of an RS PDU. 
25 Figure 84 is a diagram representing the format of an RSAK PDU. 

Figure 85 is a diagram representing the format of an ER PDU. 

Figure 86 is a diagram representing the format of an ERAK PDU. 

Figure 87 is a diagram representing the frame format of an MDU and the frame format on the broadcasting channel 
(BCCH). 

30 Figure 88 is a diagram representing the frame format of an MDU and the frame format on the perch channel (PCH). 
Figure 89 is a diagram representing the frame format of an MDU and the format of long and short frame on the ran- 
dom access channel (RACH). 

Figure 90 is a diagram representing the frame format of an MDU and the format of long frame on the forward 
access channel (FACH). 

35 Figure 91 is a diagram representing the frame format of an MDU and the format of short frame on the forward 
access channel (FACH). 

Figure 92 is a diagram representing the frame format of an MDU and the frame format on the stand alone dedicated 
control channel (SDCCH) 

Figure 93 is a diagram representing the frame format of an MDU and the frame format on the associated control 
40 channel (ACCH). 

Figure 94 is a diagram representing the frame format of an MDU and the frame format on the user packet channel 
(UPCH) 

Figure 95 is a conceptual diagram representing an example of the radio interface protocol architecture of layer 3 of 
the invented system. 

45 Figure 96 represents the basic format of RBC entity message of the invented system. 
Figure 97 represents structures of frames of an RBC entity message. 

Figure 98 is a diagram representing a common structure of CC (call/connection control) entity protocol messages. 
Figure 99 is a diagram representing a protocol discriminator of the CC entity protocol messages. 
Figure 100 is a diagram representing a call reference of the CC entity protocol messages. 
so Figure 1 01 is a diagram representing a dummy call reference of the CC entity protocol messages. 

Figure 102 is a diagram representing the format of a message type identifier of each CC entity message. 
Figures 103 and 104 are diagrams respectively representing the formats of variable length information elements 
according to FPLMTS. 

Figure 105 is a diagram representing the coding format of a broadband locking shift information element. 
55 Figure 1 06 is a diagram representing the coding format of a broadband non-locking shift information element. 

Figures 107 through 1 1 1 form a diagram representing the coding format of an AAL parameter information element. 
Figure 1 12 is a diagram representing the format of an ATM traffic descriptor information element 
Figure 1 13 is a cSagram representing the format of a broadband bearer capability information element 
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Figure 1 14 is a diagram representing the format of a broadband high layer information element. 

Figures 1 15 and 116 form a diagram representing the format of a broadband low layer information element. 

Figure 1 17 is a diagram representing the format of a called party number information element. 

Figure 1 18 is a diagram representing the format of a called party sub-address information element. 
5 Figure 1 1 9 is a diagram representing the format of a calling party number information element. 

Figure 120 is a diagram representing the format of a calling party sub-address information element. 

Figure 121 is a diagram representing the format of a connection identifier information element. 

Figure 122 is a diagram representing the format of an end-to-end transit delay information element. 

Figure 123 is a diagram representing the format of a QOS (quality of service) parameter information element. 
w Figure 124 is a diagram representing the format of a broadband repeat indicator information element. 

Figure 125 is a diagram representing the format of a broadband sending complete information element. 

Figure 126 is a diagram representing the format of a transit network selection information element. 

Figure 127 is a diagram representing the format of a notification indicator information element. 

Figure 128 is a diagram representing the format of an OAM traffic descriptor information element. 
is Figure 129 is a diagram representing the format of a narrow-band bearer capability information element. 

Figure 130 is a diagram representing the format of a narrow-band high layer compatibility information element. 

Figure 131 is a diagram representing the format of a narrow-band low layer compatibility information element. 

Figure 132 is a diagram representing the format of a progress indicator information element. 

Figure 133 is a diagram representing the format of a TMUI information element. 
20 Figure 1 34 is a diagram representing the format of a TMUI assignment source ID. 

Figure 135 is a diagram representing the format of an IMUI. 

Figure 136 is a diagram representing the format of an execution authentication type. 

Figure 137 is a diagram representing the format of an authentication random pattern. 

Figure 138 is a diagram representing the format of an authentication ciphering pattern. 
25 Figure 1 39 is a diagram representing the format of an execution ciphering type. 

Figure 140 is a diagram representing the format of a TC information. 

Figure 141 is a diagram representing the format of a message type identifier of the RBC entity message. 

Figure 142 is a diagram representing the format of an information element identifier. 

Figure 143 is a diagram representing the format of a radio bearer setup message specific parameter. 
30 Figure 1 44 is a diagram representing the format of a radio bearer release message specific parameter. 

Figure 145 is a diagram representing the format of a radio bearer release complete message specific parameter. 

Figure 146 is a diagram representing the format of a handover command message specific parameter. 

Figure 147 is a diagram representing the format of a handover response message specific parameter. 

Figures 148 to 151 form a diagram representing the format of a radio bearer setup information. 
35 Figures 152 through 154 form a diagram representing the format of a DHO (diversity handover) branch addition 

information element. 

Figure 155 is a diagram representing the format of a DHO (diversity handover) branch deletion information ele- 
ment. 

Figure 156 is a diagram representing the format of an ACCH replacement information element. 
40 Figures 1 57 through 1 59 form a diagram representing the format of a branch replacement information element. 

Figures 160 through 163 form a diagram representing the format of a user rate replacement information element. 

Figures 164 and 165 form a diagram representing the format of a code replacement information element. 

Figure 166 is a diagram representing the format of a message type identifier in RRC entity messages. 

Figure 167 is a diagram representing the format of a facility information element. 
45 Figure 168 and 169 form a diagram representing the format of an ROSE PDU. 

Figure 1 70 is a diagram representing the common format of parameters of number of visited candidate sectors, 

number of in-use visited sectors, number of candidate sectors to be added at DHO, number of sectors to be deleted 

at DHO, and candidate sectors for HHO. 

Figure 171 is a diagram representing the format of a BTS number parameter. 
so Figure 1 72 is a diagram representing the format of a sector number parameter. 

Figure 173 is a diagram representing the format of a perch channel reception SIR parameter. 

Figure 174 is a diagram representing the format of a perch channel transmission power parameter. 

Figure 1 75 is a diagram representing the format of a long code phase difference parameter. 

Figure 1 76 is a diagram representing the format of a parameter of the number of RBC IDs. 
55 Figure 1 77 is a diagram representing the format of a parameter of the RBC ID. 

Figure 1 78 is a diagram representing the format of a parameter of the necessary SIR. 

Figure 1 79 is a diagram representing the format of a parameter of FER measurement. 

Figure 180 is a diagram representing the format of a TAC entity message. 
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Figure 181 is a diagram representing the format of a protocol discriminator. 
Figure 1 82 is a diagram representing the for mat of a message type identifier 

Figure 183 is a diagram representing the format of a terminal association setup message specific parameter. 

Figure 184 is a diagram representing the format of a paging response message specific parameter. 
5 Figure 185 is a diagram representing the format of a terminal association release message specific parameter. 

Figure 186 is a diagram representing the format of a cause information element. 

Figure 1 87 is a diagram representing the format of a mobile station type information element. 

Figure 188 is a diagram representing the format of a paged MS ID information element. 

Figure 189 is a diagram representing the format of a paging ID information element. 
w Figure 190 is a diagram representing the format of a TMUI information element. 

Figure 191 is a diagram representing the format of an extensional information element for TAC entity messages. 

Figure 192 is a diagram representing the format of a message type information element. 

Figure 193 is a diagram representing the format of a length information element. 

Figure 194 is a diagram representing the format of a perch channel reception SIR information element. 
is Figure 1 95 is a diagram representing the format of a short code number information element. 

Figure 196 is a diagram representing the format of a frame offset group information element. 

Figure 197 is a diagram representing the format of a slot offset group information element. 

Figure 198 is a diagram representing the format of a network number group information element. 

Figure 199 is a diagram representing the format of a network version information element. 
20 Figure 200 is a diagram representing the format of a mobile station common parameter version information ele- 
ment. 

Figure 201 is a diagram representing the format of a BTS number information element. 
Figure 202 is a diagram representing the format of a sector number information element. 
Figure 203 is a diagram representing the format of an information element indicating the number (N) of registration 
25 areas overlapped in one radio zone. 

Figure 204 is a diagram representing the format of an area number information element. 
Figure 205 is a diagram representing the format of an information element indicating the calibrated power level nec- 
essary for reception at the base station. 

Figure 206 is a diagram representing the format of an information element indicating the calibrated power level nec- 
30 essary for reception at the base station. 

Figure 207 is a diagram representing the format of an information element indicating the number (M) of perch chan- 
nel LC for determination of visited zone. 

Figure 208 is a diagram representing the format of an information element indicating the number (K) of frequency 
bands used by base station. 
35 Figure 209 is a diagram representing the format of a frequency band information element. 

Figure 210 is a diagram representing the format of a BCCH reception duration information element. 

Figure 211 is a diagram representing the format of an information element indicating the number of paged mobile 

stations. 

Figure 212 is a diagram representing the format of a paged MS ID information element. 
40 Figure 213 is a diagram representing the format of a paging ID information element. 

Figure 214 is a conceptual diagram representing the protocol architecture on a BTS-MCC interface. 
Figure 21 5 is a diagram representing the format of a BC entity message. 
Figure 21 6 is a diagram representing the format of a BSM entity message. 

Figure 217 is a diagram representing the format of the pattern of fundamental information elements in the BSM 
45 entity message. 

Figure 218 is a diagram representing the format of the pattern of each fundamental information element in the BC 
entity message. 

Figure 219 is a diagram representing the format of a protocol discriminator of a BC entity message. 

Figure 220 is a diagram representing the format of a message type identifier of a BC entity message. 
so Figure 221 is a diagram representing the format of a parameter of link reference of a BC entity message. 

Figure 222 is a diagram representing the format of an information element identifier of a BC entity message. 

Figure 223 is a diagram representing the format of a length of information element of a BC entity message. 

Figure 224 is a diagram representing the format of an AAL type parameter of a BC entity message. 

Figure 225 is a diagram representing the format of a link identifier of a BC entity message. 
55 Figure 226 is a diagram representing the format of a transmission quality parameter of a BC entity message. 

Figure 227 is a cfiagram representing the format of a sector number of a BC entity message. 

Figure 228 is a diagram representing the format of a bearer capability parameter of a BC entity message. 

Figure 229 is a diagram representing the format of a frequency selection information of a BC entity message. 
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Figure 230 is a diagram representing the format of a frequency of a BC entity message. 

Figure 231 is a diagram representing the format of a frame offset group parameter of a BC entity message. 

Figure 232 is a diagram representing the format of a slot offset group of a BC entity message. 

Figure 233 is a diagram representing the format of a long code phase difference parameter of a BC entity message. 

Figure 234 is a diagram representing the format of a reverse long code number of a BC entity message. 

Figure 235 is a diagram representing the format of a reverse short code type parameter of a BC entity message. 

Figure 236 is a diagram representing the format of a parameter of the number of reverse short codes of a BC entity 

message. 

Figure 237 is a diagram representing the format of a reverse short code number of a BC entity message. 
Figure 238 is a diagram representing the format of a forward short code type parameter of a BC entity message. 
Figure 239 is a diagram representing the format of a parameter of number of forward short codes of a BC entity 
message. 

Figure 240 is a diagram representing the format of an AAL type parameter for ACCH of a BC entity message. 

Figure 241 is a diagram representing the format of a link identifier for ACCH of a BC entity message. 

Figure 242 is a diagram representing the format of a transmission quality for ACCH of a BC entity message. 

Figure 243 is a diagram representing the format of a forward short code number of a BC entity message. 

Figure 244 is a diagram representing the format of a result parameter of a BC entity message. 

Figure 245 is a diagram representing the format of a cause parameter of a BC entity message. 

Figure 246 is a diagram representing the format of an initial transmission power parameter of a BC entity message. 

Figure 247 is a diagram representing the format of a location identity parameter of a BC entity message. 

Figure 248 is a diagram representing the format of a protocol discriminator of a BSM entity message. 

Figure 249 is a diagram representing the format of a message type identifier of a BSM entity message. 

Figure 250 is a diagram representing the format of a PCHs calculation information of a BSM entity message. 

Figure 251 is a diagram representing the format of an area number of a BSM entity message. 

Figure 252 is a diagram representing the format of a paged MS ID of a BSM entity message. 

Figure 253 is a diagram representing the format of a paging ID of a BSM entity message. 

Figure 254 represents an SDL diagram for base station management. 

Figure 255 represents an SDL diagram for bearer control in the SDCCH executed in the BSC function of the net- 
work 

Figure 256 represents an SDL diagram for bearer control in the TCH/ACCH executed in the BSC function of the 
network. 

Figure 257 represents an SDL diagram for bearer control in the SDCCH executed in the BTS. 

Figure 258 represents an SDL diagram for bearer control in the TCH/ACCH executed in the BTS. 

Figure 259 is a diagram showing radio zones and a travelling mobile station in the invented system for describing 

an exemplified handover process. 

Figure 260 is a block diagram showing an example of mobile communications system wherein a mobile station 
communicates through a plurality of calls. 

Figure 261 is a block diagram showing the invented mobile communications system wherein a mobile station com- 
municates through a plurality of calls and capable of replacing an associated control channel. 
Figure 262 is a sequential diagram representing the ACCH replacement procedure carried out by the invented sys- 
tem. 

Figure 263 is a diagram showing the OSI reference model. 

Figure 264 is a diagram representing a sequential operation by the network and a mobile station MS in the invented 
system, which starts after a call attempt comes in the network. 

Figure 265 is a table indicating the glossary of the abbreviations used in the present specification. 
Figure 266 is a table representing the features of services provided by the invented system. 
Figure 267 is a table representing the features of the voice bearer service at 8 kbps provided by the invented sys- 
tem. 

Figure 268 is a table representing the features of the unrestricted bearer service at 64 kbps provided by the 
invented system. 

Figure 269 is a table representing the features of the multiple-rate unrestricted bearer service provided by the 
invented system. 

Figure 270 is a table representing the correlation between FE numbers and functional entities in the system. 
Figure 271 is a table representing the correlation between the relationship designations and the related functional 
entities. 

Figure 272 is a table representing the detail of a TA SETUP request indication. 
Figure 273 is a table representing the detail of another TA SETUP request indication. 
Figure 274 is a table representing the detail of a TA SETUP PERMISSION request indication. 
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Figure 275 is a table representing the detail of a REVERSE LONG CODE RETRIEVAL request indication used to 
retrieve the reverse long code. 

Figure 276 is a table representing the detail of another REVERSE LONG CODE RETRIEVAL request indication 
used to retrieve the reverse long code, 
s Figure 277 is a table representing the detail of a REVERSE LONG CODE RETRIEVAL response confirmation used 
to retrieve the reverse long code. 

Figure 278 is a table representing the detail of a TERMINAL STATUS UPDATE request indication used to update 
the terminal status. 

Figure 279 is a table representing the detail of a TERMINAL STATUS UPDATE response confirmation. 
w Figure 280 is a table representing the detail of an ADD-ROUTING INFORMATION request indication sent to an 
LRDF to add the muting address to the subscriber's profile. 

Figure 281 is a table representing the detail of an ADD-ROUTING INFORMATION response confirmation. 
Figure 282 is a table representing the detail of a TA SETUP PERMISSION response confirmation issued by the 
LRCF to inform the TACF that the mobile terminal access to the network is authorized. 
75 Figure 283 is a table representing the detail of a REVERSE LONG CODE RETRIEVAL response confirmation used 
to retrieve the reverse long code. 

Figure 284 is a table representing the detail of a TA SETUP response confirmation used to notify that the terminal 
access has been established. 

Figure 285 is a table representing the detail of another TA SETUP response confirmation used to confirm that the 
20 setup of terminal access and the connection between a CCAF and TACAF have been completed. 

Figure 286 is a table representing the detail of a SETUP request indication used to request the establishment of a 
connection. 

Figure 287 is a table representing the detail of a TACF INSTANCE ID INDICATION request indication used to 
retrieve the reverse long code. 
25 Figure 288 is a table representing the detail of a CELL CONDITION MEASUREMENT request indication. 

Figure 289 is a table representing the detail of a CELL CONDITION MEASUREMENT response confirmation that 
provides the result of the cell selection information measurement requested by the CELL CONDITION MEASURE- 
MENT request indication. 

Figure 290 is a table representing the detail of a CELL CONDITION REPORT request indication. 
30 Figure 291 is a table representing the detail of a CALL SETUP PERMISSION request indication issued by an SSF 
to request the authorization of the calling user. 

Figure 292 is a table representing the detail of a USER PROFILE RETRIEVAL request indication used to request 
the user profile to be retrieved. 

Figure 293 is a table representing the detail of a USER PROFILE RETRIEVAL response confirmation. 
35 Figure 294 is a table representing the detail of a CALL SETUP PERMISSION response confirmation issued by the 
LRCF to inform the calling user is authorized. 

Figure 295 is a table representing the detail of a SETUP request indication used to request the establishment of a 
connection. 

Figure 296 is a table representing the detail of a PROCEEDING request indication. 
40 Figure 297 is a table representing the detail of a MEASUREMENT CONDITION NOTIFICATION request indication 
used by the network to indicate conditions, which the mobile terminal measures, and to report the cell selection 
information. 

Figure 298 is a table representing the detail of another MEASUREMENT CONDITION NOTIFICATION request 
indication used by the network to indicate conditions, which the mobile terminal measures, and to report cell select- 
45 ing information. 

Figure 299 is a table representing the detail of a REPORT request indication used to report status and/or other 
types of information (e.g. alerting, suspended, hold, and resume) transported within the network. 
Figure 300 is a table representing the detail of another REPORT request indication used to report status and/or 
other types of information (e.g. alerting, suspended, hold, and resume) transported within the network. 
so Figure 301 is a table representing the detail of a SETUP response confirmation used to confirm that the connection 
has been established. 

Figure 302 is a table representing the detail of another SETUP response confirmation used to confirm that the con- 
nection has been established. 

Figure 303 is a table representing the detail of a SETUP request indication used to report the establishment of a 
55 connection. 

Figure 304 is a table representing the detail of a ROUTING INFORMATION QUERY request indication used to 
inquire the routing information. 

Figure 305 is a table representing the detail of a TERMINAL ID RETRIEVAL request indication used to request the 
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user profile to be retrieved. 

Figure 306 is a table representing the detail of a TERMINAL ID RETRIEVAL response confirmation that is the 
response to the TERMINAL ID RETRIEVAL request indication. 

Figure 307 is a table representing the detail of a TERMINAL STATUS QUERY request indication used to inquire the 
5 terminal status (e.g. if terminal access is active or not). 

Figure 308 is a table representing the detail of a TERMINAL STATUS QUERY response confirmation that is the 
response to the TERMINAL STATUS QUERY request indication. 

Figure 309 is a table representing the detail of a TERMINAL STATUS UPDATE request indication used to update 
the terminal status. 

io Figure 310 is a table representing the detail of a TERMINAL STATUS UPDATE response confirmation that is the 
response to the TERMINAL STATUS UPDATE request indication. 

Figure 31 1 is a table representing the detail of a PAGING AREA QUERY request indication used to inquire the pag- 
ing area where TACF resides when it is observed that the terminal access is not active. Figure 312 is a table rep- 
resenting the detail of a PAGING AREA QUERY response confirmation is the response to the PAGING AREA 
15 QUERY request indication. 

Figure 313 is a table representing the detail of a PAGE request indication used to trigger a TACF of paging. 
Figure 314 is a table representing the detail of a PAGING request indication used to page a mobile terminal for 
determining its position in the network and for the routing for a call. 

Figure 315 is a table representing the detail of a PAGING response confirmation used to respond to the request 
20 indication. 

Figure 316 is a table representing the detail of a PAGE response confirmation that is the response to the request 
indication and notifies a LRCF of the paging result. 

Figure 317 is a table representing the detail of a REVERSE LONG CODE RETRIEVAL request indication used to 
retrieve the reverse long code. 

25 Figure 318 is a table representing the detail of another REVERSE LONG CODE RETRIEVAL request indication 
used to retrieve the reverse long code. 

Figure 31 9 is a table representing the detail of a REVE RSE LONG CODE RETRIEVAL response confirmation used 
to retrieve the reverse long code. 

Figure 320 is a table representing the detail of a CELL CONDITION MEASUREMENT request indication used by 
30 the MRRC to trigger the measurement of cell selecting information. 

Figure 321 is a table representing the detail of a CELL CONDITION MEASUREMENT response confirmation pro- 
vides the result of the cell selection information measurement requested by the CELL CONDITION MEASURE- 
MENT request indication. 

Figure 322 is a table representing the detail of a CELL CONDITION REPORT request indication used by the mobile 
35 terminal to report the cell selection information. 

Figure 323 is a table representing the detail of an ADD-ROUTING INFORMATION request indication sent to the 
LRDFp to add the routing information to the subscriber's profile. 

Figure 324 is a table representing the detail of an ADD-ROUTING INFORMATION response confirmation that is 
the response to the ADD-ROUTING INFORMATION request indication. 
40 Figure 325 is a table representing the detail of a PAGE AUTHORIZED request indication at relationship rg used to 
notify the TACF of the result of the terminal authentication. 

Figure 326 is a table representing the detail of a REVERSE LONG CODE RETRIEVAL response confirmation used 
to retrieve the reverse long code. 

Figure 327 is a table representing the detail of a ROUTING INFORMATION QUERY response confirmation that is 
45 the response to the request indication. 

Figure 328 is a table representing the detail of a SETUP request indication used to request the establishment of a 
connection. 

Figure 329 is a table representing the detail of a TERMINATION ATTEMPT request indication used to request the 
user's profile which may be needed to proceed the call process. 
so Figure 330 is a table representing the detail of a USER PROFILE RETRIEVAL request indication used to retrieve 
the called user's profile from the LRDF 

Figure 331 is a table representing the detail of a USER PROFILE RETRIEVAL response confirmation that is the 
response to the request indication from the LRCF. 

Figure 332 is a table representing the detail of a TERMINATION ATTEMPT response confirmation that is the 
55 response to the request indication from the SSF. 

Figure 333 is a table representing the detail of a SETUP request indication used to request the establishment of a 
connection. 

Figure 334 is a table representing the detail of a PROCEEDING request indication optionally reports that the 
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received connection setup is valid and authenticated and that further routing and progressing of the call is proceed- 
ing. 

Figure 335 is a table representing the detail of a MEASUREMENT CONDITION NOTIFICATION request indication 
used by the network to indicate conditions, which the mobile terminal measures, and to report the cell selection 
information. 

Figure 336 is a table representing the detail of a REPORT request indication used to report status and/or other 
types of information transported in the network. 

Figure 337 is a table representing the detail of a SETUP response confirmation used to confirm that the connection 
has been established. 

Figure 338 is a table representing the detail of a CONNECTED request indication used to acknowledge that a pre- 
viously sent SETUP response confirmation has been received and accepted. 

Figure 339 is a table representing the detail of a RELEASE request indication used to release the resources asso- 
ciated with the call connection, such as call ID and channels. 

Figure 340 is a table representing the detail of a RELEASE response confirmation used to indicate that all 
resources pervasively associated with the connection have been released. 

Figure 341 is a table representing the detail of a TA RELEASE request indication used to inform an SCF that the 
attempt of call release has been detected. 

Figure 342 is a table representing the detail of a TERMINAL-STATUS-MAKE-IDLE request indication used to idle 
the terminal call status. 

Figure 343 is a table representing the detail of a TERMINAL-STATUS-MAKE- IDLE response confirmation that is 
the response to the TERMINAL-STATUS-MAKE-IDLE request indication. 

Figure 344 is a table representing the detail of a TA RELEASE response confirmation used for the confirmation to 
the TA RELEASE request indication. 

Figure 345 is a table representing the detail of a RELEASE request indication used to release the resources asso- 
ciated with the call connection such as the call reference and channels. 

Figure 346 is a table representing the detail of a RELEASE response confirmation used to indicate that all 
resources previously associated with the connection have been released. 

Figure 347 is a table representing the detail of a TA RELEASE request indication issued by the TACF to inform the 
LRCF that the attempt of call release has been detected. 

Figure 348 is a table representing the detail of a TERMINAL-STATUS-MAKE-IDLE request indication used to idle 
the terminal call status. 

Figure 349 is a table representing the detail of a TERMINAL- STATUS-MAKE- IDLE response confirmation that is 
the response to the TERMINAL-STATUS-MAKE- IDLE request indication. 

Figure 350 is a table representing the detail of a TA RELEASE response confirmation used for a confirmation of the 
TERMINAL-STATUS-MAKE-IDLE request indication. 

Figure 351 is a table representing the detail of a RADIO LINK FAILURE request indication used to notify a radio 
link failure detected by a BCAF or BCFr. 

Figure 352 is a table representing the detail of a RELEASE NOTIFICATION request indication used to indicate that 
a connection between the network and the terminal has been released. 

Figure 353 is a table representing the detail of a RADIO LINK FAILURE request indication used to notify that the 
link failure has been detected. 

Figure 354 is a table representing the detail of another RADIO LINK FAILURE request indication used to notify that 
the link failure has been detected. 

Figure 355 is a table representing the detail of a RADIO LINK FAILURE response confirmation that is a response 
confirmation of the RADIO LINK FAILURE request indication. 

Figure 356 is a table representing the detail of a RADIO BEARER RELEASE request indication used to request to 
release radio bearers. 

Figure 357 is a table representing the detail of a BEARER RELEASE request indication issued by the TACF to the 
BCF to release the radio bearer. 

Figure 358 is a table representing the detail of a BEARER RELEASE response confirmation that is a response con- 
firmation of the BEARER RELEASE request indication. 

Figure 359 is a table representing the detail of another BEARER RELEASE request indication sent by an anchor 
TACF to request a serving TACF to release the bearer involved in the call that should be released. 
Figure 360 is a table representing the detail of another BEARER RELEASE request indication issued by the TACF 
to BCF to release the radio bearer. 

Figure 361 is a table representing the detail of another BEARER RELEASE response confirmation that is a 
response confirmation of the BEARER RELEASE request indication. 

Figure 362 is a table representing the detail of a BEARER-AND-RADIO-BEARER RELEASE request indication 
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issued by the TACF to release the bearer-and-radio-bearer. 

Figure 363 is a table representing the detail of a BEARER-AND-RADIO-BEARER RELEASE response confirma- 
tion used for a confirmation of the release of the bearer-and-radio-bearer requested by the BEARER-AND-RADIO- 
BEARER RELEASE request indication. 
5 Figure 364 is a table representing the detail of another BEARER RELEASE response confirmation that is a confir- 
mation response to inform the TACF that the previous request to release the radio bearer has been completed. 
Figure 365 is a table representing the detail of a TA RELEASE request indication issued by the TACF to inform the 
LRCF that the attempt of releasing call has detected. 

Figure 366 is a table representing the detail of a TERMINAL-STATUS-MAKE-IDLE request indication used to 
10 request to update the user profile. 

Figure 367 is a table representing the detail of a TERMINAL-STATUS-MAKE- IDLE response confirmation that is a 
response to the TERMINAL-STATUS-MAKE- IDLE request indication. 

Figure 368 is a table representing the detail of a TA RELEASE response confirmation used for a response confir- 
mation of the TA RELEASE request indication. 
75 Figure 369 is a table representing the detail of a RADIO LINK FAILURE request indication used to notify that a link 
failure has been detected and reported by either BCFr or BCFa. 

Figure 370 is a table representing the detail of another RADIO LINK FAILURE request indication used to notify that 
the link failure has been detected. 

Figure 371 is a table representing the detail of a RADIO LINK FAILURE response confirmation that is a confirma- 
20 tion response to the RADIO LINK FAILURE request indication. 

Figure 372 is a table representing the detail of a RADIO BEARER RELEASE request indication used to request to 
release the radio bearer. 

Figure 373 is a table representing the detail of a RELEASE NOTIFICATION request indication used to indicate that 
the connection between the network and the terminal has been released. 
25 Figure 374 is a table representing the detail of a RADIO BEARER RELEASE response confirmation that is a 
response confirmation of the RADIO BEARER RELEASE request indication. 

Figure 375 is a table representing the detail of a BEARER RELEASE request indication issued by the TACF to BCF 
to release the radio bearer. 

Figure 376 is a table representing the detail of a BEARER RELEASE response confirmation that is a response con- 

30 firmation of the BEARER RELEASE request indication. 

Figure 377 is a table representing the detail of another BEARER RELEASE request indication sent by the anchor 
TACF to request the serving TACF to release the radio bearer involved in the call that should be released. 
Figure 378 is a table representing the detail of another BEARER RELEASE request indication issued by the TACF 
to BCF to release the radio bearer. 

35 Figure 379 is a table representing the detail of a BEARER RELEASE response confirmation that is a response con- 
firmation of the BEARER RELEASE request indication. 

Figure 380 is a table representing the detail of a BEARER-AND-RADIO-BEARER RELEASE request indication 
issued by the TACF to release the bearer and radio bearer. 

Figure 381 is a table representing the detail of a BEARER-AND-RADIO-BEARER RELEASE response confirma- 
40 tion used for a confirmation of the release of the bearer and radio bearer requested by the BEARER-AND-RADIO- 
BEARER RELEASE request indication. 

Figure 382 is a table representing the detail of another BEARER RELEASE response confirmation that is a confir- 
mation response for informing the TACF that the previous request to release the radio bearer has been completed. 
Figure 383 is a table representing the detail of a RADIO BEARER RELEASE request indication issued to request 

45 to release the radio bearer. 

Figure 384 is a table representing the detail of another RADIO BEARER RELEASE response confirmation used to 
confirm the release of radio bearer requested by the RADIO BEARER RELEASE request indication. 
Figure 385 is a table representing the detail of a TA RELEASE request indication issued by the TACF to inform the 
LRCF that the attempt of call release has been detected. 

so Figure 386 is a table representing the detail of a TERMINAL-STATUS-MAKE- IDLE request indication used to 
request to update the user profile. 

Figure 387 is a table representing the detail of a TERMINAL-STATUS-MAKE -IDLE response confirmation that is a 
response to the TERMINAL-STATUS-MAKE-IDLE request indication. 

Figure 388 is a table representing the detail of another TA RELEASE response confirmation is used for confirma- 
55 tion to the TA RELEASE request indication. 

Figure 389 is a table representing the detail of a CALL DISCONNECT request indication used to notify the LRCF 
that a "user disconnect" has been detected. 

Figure 390 is a table representing the detail of a USER-PROFILE -UP DATE request indication used to request to 
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update the user profile. 

Figure 391 is a table representing the detail of a USER-PROFILE-UPDATE response confirmation that is a 
response to the USER-PROFILE-UPDATE response confirmation. 

Figure 392 is a table representing the detail of a CALL DISCONNECT response confirmation that is a response to 
5 the request made by the CALL DISCONNECT request indication. 

Figure 393 is a table representing the detail of a SIGNALING CHANNEL SETUP REQUEST request indication 
used by the MCF and TACF to request the network to setup the signaling channels. 

Figure 394 is a table representing the detail of a SIGNALING CHANNEL SETUP request indication used by an 
SCMAF to request to the network to allocate the signaling channels. 
w Figure 395 is a table representing the detail of a SIGNALING CHANNEL SETUP response confirmation used by 
the SCMF to allocate the radio resources to the signaling channels. 

Figure 396 is a table representing the detail of a SIGNALING CHANNEL SETUP REQUESTED request indication 
used to indicate the reception of the signaling channel setup request (initial access detection) from the mobile ter- 
minal and to request the network to setup the corresponding signaling channels in the network. 
15 Figure 397 is a table representing the detail of a SIGNALING CONNECTION SETUP request indication used by 
the TACF and SACF to setup the signaling connection among them and the SCMF 

Figure 398 is a table representing the detail of a SIGNALING CONNECTION SETUP response confirmation used 
to report the establishment of the signaling channels including the physical radio channel and the intra-network 
channel. 

20 Figure 399 is a table representing the detail of a SIGNALING CHANNEL SETUP REQUEST response confirmation 
used by the SCMAF to report the setup of the signaling channels to the network. 

Figure 400 is a table representing the detail of a BEARER SETUP request indication used to request the establish- 
ment of the access bearer from the CCF to TACF. 

Figure 401 is a table representing the detail of a CHANNEL SELECTION response confirmation used to report 
25 reserved radio resources to the TACF, which requested the reservation. 

Figure 402 is a table representing the detail of a BEARER SETUP request indication sent from the TACF to BCF to 
request the establishment of the access bearer. 

Figure 403 is a table representing the detail of a BEARE R SETUP response confirmation sent to confirm the estab- 
lishment of the access bearer and to indicate the bearer ID of the bearer between the BCF and BCF 
30 Figure 404 is a table representing the detail of another BEARER SETUP request indication used to request the 
establishment of the access bearer from the TACFa to TACFv. 

Figure 405 is a table representing the detail of another BEARER SETUP request indication sent from the TACF to 
BCF to request the establishment of the access bearer. 

Figure 406 is a table representing the detail of another BEARER SETUP response confirmation sent from the BCF 

35 to TACF to request the establishment of the access bearer. 

Figure 407 is a table representing the detail of a BEARER-AND-RADIO-BEARER SETUP request indication sent 
from the TACF to BCFr to request the establishment of the radio bearer and the bearer between the BCF and BCFr. 
Figure 408 is a table representing the detail of a RADIO BEARER SETUP PROCEEDING request indication used 
by the BCFr to report that the instructed radio bearer setup is valid and the establishment of the radio bearer is pro- 

40 ceeding. 

Figure 409 is a table representing the detail of a RADIO BEARER SETUP REQUEST request indication issued by 
the TACF, which controls a new access bearer, to the TACK which has the signaling connection, to request to newly 
assign a radio bearer to the mobile terminal. 

Figure 410 is a table representing the detail of a RADIO BEARER SETUP request indication sent from the TACF 
45 to TACAF to request the establishment of the radio bearer. 

Figure 411 is a table representing the detail of another RADIO BEARER SETUP request indication sent from the 
TACAF to BCAF to request the establishment of the radio bearer. 

Figure 412 is a table representing the detail of a RADIO BEARER SETUP response confirmation sent from the 
BCAF to TACAF to confirm that the establishment of radio bearer has been completed. 
so Figure 413 is a table representing the detail of a BEARER-AND-RADIO-BEARER SETUP response confirmation 
sent to confirm that the establishment of radio bearer and bearer between the BCF and BCFr have been com- 
pleted. 

Figure 414 is a table representing the detail of a BEARER SETUP response confirmation used to confirm that the 
establishment of access bearer has been completed. 
55 Figure 415 is a table representing the detail of another BEARER SETUP response confirmation used to confirm 
that the establishment of access bearer has been completed. 

Figure 416 is a table representing the detail of a BEARER RELEASE request indication sent by an anchor CCF to 
notify an anchor TACF that the attempt or event of call release has been detected and that the bearer involved in 
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the call is being released. 

Figure 41 7 is a table representing the detail of a RADIO BEARER RELEASE request indication used by the TACFa 
to request to release the radio bearer. 

Figure 418 is a table representing the detail of a RADIO BEARER RELEASE response confirmation that is a 
5 response confirmation of the RADIO BEARER RELEASE request indication. 

Figure 419 is a table representing the detail of a BEARER RELEASE request indication issued by the TACF to BCF 
to release the radio bearer. 

Figure 420 is a table representing the detail of a BEARER RELEASE response confirmation that is a response con- 
firmation of the BEARER RELEASE request indication. 
w Figure 421 is a table representing the detail of another BEARER RELEASE request indication sent by the TACFa 
to request the TACFv to release the bearer involved in the call is being released. 

Figure 422 is a table representing the detail of another BEARER RELEASE request indication issued by the TACF 
to BCF to release the radio bearer. 

Figure 423 is a table representing the detail of a BEARER RELEASE response confirmation that is a response con- 
15 firmation of the BEARER RELEASE request indication. 

Figure 424 is a table representing the detail of a BEARER-AND-RADIO-BEARER RELEASE request indication 
issued by the TACF to release the bearer and radio bearer. 

Figure 425 is a table representing the detail of a BEARER-AND-RADIO-BEARER RELEASE response confirma- 
tion used for a confirmation of the release of the bearer and radio bearer requested by the BEARER-AND-RADIO- 
20 BEARER RELEASE request indication. 

Figure 426 is a table representing the detail of another BEARER RELEASE response confirmation that is a confir- 
mation of the BEARER RELEASE request indication. 

Figure 427 is a table representing the detail of another BEARER RELEASE response confirmation that is a 
response confirmation to inform the CCF that the previous request to release the radio bearer has been completed. 
25 Figure 428 is a table representing the detail of another RADIO BEARER RELEASE request indication issued by 
the TACAF to request the radio bearer release. 

Figure 429 is a table representing the detail of another RADIO BEARER RELEASE request indication used by the 
BOCA to confirm the radio bearer release requested by the RADIO BEARER RELEASE request indication. 
Figure 430 is a table representing the detail of a SIGNALING CHANNEL RELEASE REQUEST request indication 
30 used by the MCF and TACF to request the release of a signaling channel. 

Figure 431 is a table representing the detail of a SIGNALING CONNECTION RELEASE request indication used by 
the TACF and SACF to request the release of the signaling channel (in both of the network and the radio 
resources). 

Figure 432 is a table representing the detail of a SIGNALING CONNECTION RELEASE response confirmation 
35 used to report the release of the signaling channel. 

Figure 433 is a table representing the detail of a BEARE R SETUP request indication sent from the TACFa to TACFv 
to request the setup of an access bearer 

Figure 434 is a table representing the detail of an INTRA-BCFr HANDOVER BRANCH ADDITION request indica- 
tion. 

40 Figure 435 is a table representing the detail of an INTRA-BCFr HANDOVER BRANCH ADDITION response con- 
firmation that is a response to the INTRA-BCFr HANDOVER BRANCH ADDITION request indication and is sent 
from the BCFr to TACF to indicate the completion of setup of the physical radio channel(s). 
Figure 436 is a table representing the detail of a RADIO BEARER SETUP REQUEST request indication sent from 
the visited TACF, which controls the newly assigned radio bearer, to TACFa to request to setup the radio bearer 

45 between the mobile terminal and BCFr controlled by the visited TACF. 

Figure 437 is a table representing the detail of a HANDOVER BRANCH ADDITION request indication sent from the 
TACF to TACAF to notify of the intra-BCFr handover branch addition, and requesting to add a new physical radio 
channel to an existing physical radio channel. 

Figure 438 is a table representing the detail of a RADIO BEARER SETUP request indication sent from the TACAF 
so to BCAF to request to setup a radio bearer. 

Figure 439 is a table representing the detail of a RADIO BEARER SETUP response confirmation that is a response 
to the RADIO BEARER SETUP request indication sent from the BCAF to TACAF to indicate the completion of the 
radio bearer setup. 

Figure 440 is a table representing the detail of a HANDOVER CONNECTION SETUP request indication notifying 
55 of a handover initiation and to request to setup an access bearer. 

Figure 441 is a table representing the detail of a HANDOVER CONNECTION SETUP response confirmation sent 

from the BCF to TACF to confirm the HANDOVER CONNECTION SETUP request indication. 

Figure 442 is a table representing the detail of a BEARER SETUP request indication sent from the TACFa to TACFv 
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to setup an access bearer. 

Figure 443 is a table representing the detail of another BEARER SETUP request indication sent from the TACF to 
BCF to request the bearer setup. 

Figure 444 is a table representing the detail of a BEARER SETUP response confirmation sent from the BCF to 
5 TACF to confirm the BEARER SETUP request indication. 

Figure 445 is a table representing the detail of a BEARER-AND-RADIO-BEARER SETUP request indication. 
Figure 446 is a table representing the detail of a BEARER-AND-RADIO-BEARER SETUP response confirmation 
sent from the BCFr to TACF to indicate the completion of setting up of the radio bearer and bearer between the 
BCFr and BCF. 

10 Figure 447 is a table representing the detail of a RADIO BEARER SETUP REQUEST request indication sent from 
the visited TACF, which controls the newly assigned radio bearer, to the TACFs to request to setup the radio bearer 
between the mobile terminal and BCFr. 

Figure 448 is a table representing the detail of a HANDOVER BRANCH ADDITION request indication notifying of 
the handover branch addition request. 
is Figure 449 is a table representing the detail of a RADIO BEARER SETUP request indication sent from the TACAF 
to BCAF. 

Figure 450 is a table representing the detail of a RADIO BEARER SETUP response confirmation sent from the 
BCAF to TACAF to indicate the completion of the radio bearer setup. 

Figure 451 is a table representing the detail of a BEARER SETUP response confirmation sent from the TACFa to 

20 TACFv to confirm the establishment of the access bearer. 

Figure 452 is a table representing the detail of a HANDOVER BRANCH DELETION request indication. 

Figure 453 is a table representing the detail of a HANDOVER BRANCH DELETION response confirmation sent 

from the TACAF to TACF to confirm the HANDOVER BRANCH DELETION request indication. 

Figure 454 is a table representing the detail of a BEARER RELEASE request indication sent from the TACFa to 

25 TACFv to release the access bearer. 

Figure 455 is a table representing the detail of an INTRA-BCFr HANDOVER BRANCH DELETION request indica- 
tion sent from the TACF to BCFr to request the release of the physical radio channels). 
Figure 456 is a table representing the detail of an INTRA-BCFr HANDOVER BRANCH DELETION response con- 
firmation sent from the BCFr to TACF to indicate the release of the physical radio channel(s). 

so Figure 457 is a table representing the detail of a BEARER RELEASE response confirmation sent from the TACFv 
to TACFa to confirm the BEARER RELEASE request indication. 

Figure 458 is a table representing the detail of a HANDOVER BRANCH DELETION request indication sent from 
the TACF to TACAF. 

Figure 459 is a table representing the detail of a HANDOVER BRANCH DELETION response confirmation sent 
35 from the TACAF to TACF to confirm the HANDOVER BRANCH DELETION request indication. 

Figure 460 is a table representing the detail of a RADIO BEARER RELEASE request indication sent from the 
TACAF to BCAF to request the radio bearer release. 

Figure 461 is a table representing the detail of a RADIO BEARER RELEASE response confirmation sent from the 
BCFr toTACAF to indicate the completion of the radio bearer release. 
40 Figure 462 is a table representing the detail of a HANDOVER CONNECTION RELEASE request indication sent 
from the TACF to BCF to release the indicated bearer in the diversity handover state. 

Figure 463 is a table representing the detail of a HANDOVER CONNECTION RELEASE response confirmation 
sent from the BCF to TACF to confirm the HANDOVER CONNECTION RELEASE request indication. 
Figure 464 is a table representing the detail of a BEARER RELEASE request indication sent from the TACFa to 
45 TACFv to release the access bearer. 

Figure 465 is a table representing the detail of another BEARER RELEASE request indication sent from the TACF 
to BCF to request the bearer release. 

Figure 466 is a table representing the detail of a BEARER RELEASE response confirmation sent from the BCF to 
TACF to confirm the BEARER RELEASE request indication. 

so Figure 467 is a table representing the detail of a BEARER-AND-RADIO-BEARER RELEASE request indication 
sent from the TACF to BCFr to request the bearer between the BCF and BCFr and the radio bearer. 
Figure 468 is a table representing the detail of a BEARER-AND-RADIO-BEARER RELEASE response confirma- 
tion sent from the BCFr to TACF to indicate the completion of the release of the bearer and the radio bearer. 
Figure 469 is a table representing the detail of a BEARER RELEASE response confirmation sent from the TACFv 

55 to TACFa to confirm the BEARER RELEASE request indication. 

Figure 470 is a table representing the detail of a BEARER SETUP request indication sent from the TACFa to TACFv 
to setup an access bearer. 

Figure 471 is a table representing the detail of an INTRA-BCFr HANDOVER BRANCH REPLACEMENT response 
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confirmation sent from the BCFr to TACF to indicate the completion of the setup of the physical radio channel(s). 
Figure 472 is a table representing the detail of an INTRA- BCFr HANDOVER BRANCH REPLACEMENT PRO- 
CEEDING request indication sent from the BCFr to TACF to indicate that the request of the handover branch 
replacement is accepted. 

5 Figure 473 is a table representing the detail of a RADIO BEARER SETUP REQUEST request indication sent from 
the visited TACF, which controls the newly assigned radio bearer, to the anchor TACFa to request to setup the radio 
bearer between the mobile terminal and BCFr controlled by the visited TACF 

Figure 474 is a table representing the detail of a NON-SOFT HANDOVER EXECUTION request indication sent 
from the TACF to TACAF to notify of a non-soft handover execution request initiation. 
w Figure 475 is a table representing the detail of a RADIO BEARER SETUP request indication sent from the TACAF 
to BCAF to request to setup a radio bearer. 

Figure 476 is a table representing the detail of a RADIO BEARER SETUP response confirmation sent from the 
BCAF to TACAF to indicate the completion of the radio bearer setup. 

Figure 477 is a table representing the detail of a RADIO BEARER RELEASE request indication sent from the 
is TACAF to BCAF to request the radio bearer release. 

Figure 478 is a table representing the detail of a RADIO BEARER RELEASE response confirmation sent from the 
BCAF to TACAF to indicate the completion of the radio bearer release. 

Figure 479 is a table representing the detail of a BEARER SETUP response confirmation sent from the TACFa to 
TACFv to confirm the establishment of the access bearer. 
20 Figure 480 is a table representing the detail of a HANDOVER CONNECTION SETUP request indication sent from 
the TACFa to BCFa to notify of a handover initiation. 

Figure 481 is a table representing the detail of a HANDOVER CONNECTION SETUP response confirmation sent 
from the BCF to TACF to confirm the HANDOVER CONNECTION SETUP request indication. 
Figure 482 is a table representing the detail of a BEARER SETUP request indication sent from the TACFa to TACFv 
25 to set up a new handover link. 

Figure 483 is a table representing the detail of another BEARER SETUP request indication sent from the TACF to 
BCF to request a new handover link in the network. 

Figure 484 is a table representing the detail of a BEARER SETUP response confirmation sent from the BCF to 

TACF to confirm a BEARER SETUP request indication. 
30 Figure 485 is a table representing the detail of a BEARE R-AND- RADIO-BEARE R SETUP request indication sent 

from the TACF to BCFr to request to set up a bearer between the BCF and BCFr and a radio bearer. 

Figure 486 is a table representing the detail of a RADIO BEARER SETUP PROCEEDING request indication sent 

from the BCFr to TACF to indicate that the request of the access radio link setup is accepted and that the BCFr 

starts setting up the access radio link. 
35 Figure 487 is a table representing the detail of a RADIO BEARER SETUP REQUEST request indication. 

Figure 488 is a table representing the detail of a NON-SOFT HANDOVER EXECUTION request indication sent 

from the TACF to TACAF to notify of a NON-SOFT HANDOVER EXECUTION request indication. 

Figure 489 is a table representing the detail of a RADIO BEARER SETUP request indication sent from the TACAF 

to BCAF to request to set up an access radio link. 
40 Figure 490 is a table representing the detail of a RADIO BEARER SETUP response confirmation sent from the 

BCAF to TACAF to indicate the completion of the setup of the access radio link. 

Figure 491 is a table representing the detail of a RADIO BEARER RELEASE request indication sent from the 
TACAF to BCAF to request to release the access radio link. 

Figure 492 is a table representing the detail of a RADIO BEARER RELEASE response confirmation sent from the 
45 BCAF to TACAF to request to release the access radio link. 

Figure 493 is a table representing the detail of a BEARER-AND-RADIO-BEARER SETUP response confirmtion 
sent from the BCFr to TACF to indicate the completion of the setup of the access radio link and the link between 
the BCFr and BCF. 

Figure 494 is a table representing the detail of a BEARER SETUP response confirmation sent from the TACFa to 
so TACFv to confirm the establishment of the handover link. 

Figure 495 is a table representing the detail of a HANDOVER CONNECTION RELEASE request indication sent 
from the TACF to BCFa to request to remove the indicated handover link. 

Figure 496 is a table representing the detail of a HANDOVER CONNECTION RELEASE response confirmation 
sent from the BCF to TACF to confirm the HANDOVER CONNECTION RELEASE request indication. 
55 Figure 497 is a table representing the detail of a BEARER RELEASE request indication sent from the TACFa to 
TACFv to request to release the handover link in the network. 

Figure 498 is a table representing the detail of another BEARER RELEASE request indication sent from the TACF 
to BCF to request to release the handover link in the network. 
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Figure 499 is a table representing the detail of a BEARER RELEASE response confirmation sent from the BCF to 
TACF to confirm the BEARER RELEASE request indication. 

Figure 500 is a table representing the detail of a BEARER-AND-RADIO-BEARER RELEASE request indication 
sent from the TACF to BCFr to request to release the access link or handover link between the BCF and BCFr and 
between BCAF and BCF 

Figure 501 is a table representing the detail of a BEARER-AND-RADIO-BEARER RELEASE response confirma- 
tion sent from the BCFr to TACF to indicate the completion of the release of the access link or hand over link. 
Figure 502 is a table representing the detail of a BEARER RELEASE response confirmation sent from the TACFv 
to TACFa to confirm the BEARER RELEASE request indication. 

Figure 503 is a table representing the detail of a HANDOVER CONNECTION SETUP request indication sent from 
a TACFa to a BAFa to notify of a handover initiation and to request to setup an ACCH. 

Figure 504 is a table representing the detail of a HANDOVER CONNECTION SETUP response confirmation sent 
from the BCF to the TACFa to confirm the HANDOVER CONNECTION SETUP request indication. 
Figure 505 is a table representing the detail of a BEARER SETUP request indication sent from the TACFa to a 
TACFv to setup an access bearer for the ACCH. 

Figure 506 is a table representing the detail of another BEARER SETUP request indication sent from the TACFv to 
the BCF to setup an access bearer for the ACCH. 

Figure 507 is a table representing the detail of a BEARER SETUP response confirmation sent from the BCF to the 
TACFv to confirm the BEARER SETUP request indication. 

Figure 508 is a table representing the detail of a BEARER-AND-RADIO-BEARER SETUP request indication sent 
from the TACFv to the BCFr. 

Figure 509 is a table representing the detail of a RADIO BEARER SETUP PROCEEDING request indication sent 
from the BCFr to the TACFv. 

Figure 510 is a table representing the detail of a RADIO BEARER SETUP REQUEST request indication. 

Figure 511 is a table representing the detail of another RADIO BEARER SETUP request indication sent from the 

TACFa to TACAF 

Figure 512 is a table representing the detail of another RADIO BEARER SETUP request indication sent from the 
TACAF to BCAF. 

Figure 513 is a table representing the detail of a RADIO BEARER SETUP response confirmation sent from the 
BCAF to the TACAF to indicate the completion of the radio bearer setup for the new ACCH. 
Figure 514 is a table representing the detail of a RADIO BEARER RELEASE request indication sent from the 
TACAF to another BCAF to request to release a previous radio bearer. 

Figure 515 is a table representing the detail of a RADIO BEARER RELEASE response confirmation sent from the 
BCAF to the TACAF to indicate the completion of the radio bearer release. 

Figure 516 is a table representing the detail of a HANDOVER CONNECTION RELEASE request indication sent 

from the TACFa to the BCFa to request to remove the previous bearer in the soft handover state. 

Figure 517 is a table representing the detail of a HANDOVER CONNECTION RELEASE response confirmation 

sent from the BCF to the TACF to confirm the HANDOVER CONNECTION RELEASE request indication. 

Figure 518 is a table representing the detail of a BEARER RELEASE request indication sent from the TACFa to 

TACFv to request to release the access bearer 

Figure 519 is a table representing the detail of another BEARER RELEASE request indication sent from the TACF 
to BCF to request to release the bearer. 

Figure 520 is a table representing the detail of a BEARER RELEASE response confirmation sent from the BCF to 
the TACF to confirm the BEARER RELEASE request indication. 

Figure 521 is a table representing the detail of a BEARER-AND-RADIO-BEARER RELEASE request indication 
sent from the TACF to BCFr to request to release the bearer between the BCF and BCFr and the radio bearer. 
Figure 522 is a table representing the detail of a BEARER-AND-RADIO-BEARER RELEASE response confirma- 
tion sent from the BCFr to TACAF to indicate the completion of the release of the bearer and radio bearer. 
Figure 523 is a table representing the detail of a BEARER RELEASE response confirmation sent from the TACFv 
to TACFa to confirm the BEARER RELEASE request indication. 

Figure 524 is a table representing the detail of a CODE REPLACEMENT request indication sent from a BCFr to a 
TACF to request change of codes. 

Figure 525 is a table representing the detail of another CODE REPLACEMENT request indication sent from the vis- 
ited TACF to a TACFa to request change of codes. 

Figure 526 is a table representing the detail of another CODE REPLACEMENT request indication sent from the 
TACF to a TACAF to request change of codes. 

Figure 527 is a table representing the detail of another CODE REPLACEMENT request indication sent from the 
TACAF to the BCAF to request to change of codes. 
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Figure 528 is a table representing the detail of a CODE REPLACEMENT response confirmation sent from the 
BCAF to the TACAF to indicate the completion of the change of codes. 

Figure 529 is a table representing the detail of another CODE REPLACEMENT response confirmation sent from 
the TACAF to the TACFa to confirm the CODE REPLACEMENT request indication. 

Figure 530 is a table representing the detail of another CODE REPLACEMENT response confirmation sent from 
the TACFa to the TACFv to confirm the CODE REPLACEMENT request indication. 

Figure 531 is a table representing the detail of another CODE REPLACEMENT response confirmation sent from 
the TACF to the BCFr to confirm the CODE REPLACEMENT request indication. 

Figure 532 is a table representing the detail of a CELL CONDITION REPORT request indication sent from an 
MRRC to an RRC periodically to notify of the radio conditions of respective handover branches. 
Figure 533 is a table representing the detail of a TRANSMISSION POWER CONTROL request indication sent from 
a TACFa to TACFv to notify of the instructed transmission power. 

Figure 534 is a table representing the detail of another TRANSMISSION POWER CONTROL request indication 
sent from a TACFv to BCFr to notify of the instructed transmission power. 

Figure 535 is a table representing the detail of an LAI UPDATE request indication sent from the visited SCF to the 
SDF. 

Figure 536 is a table representing the detail of a TERMINAL LOCATION UPDATE request indication sent from the 
SACF to the visited SCF. 

Figure 537 is a table representing the detail of another TERMINAL LOCATION UPDATE request indication sent 
from the MCF to the SACF. 

Figure 538 is a table representing the detail of an AUTHENTICATION INFORMATION RETRIEVAL request indica- 
tion and an AUTHENTICATION INFORMATION RETRIEVAL response confirmation. 

Figure 539 is a table representing the detail of an AUTHENTICATION CHALLENGE request indication and the 
AUTHENTICATION CHALLENGE response confirmation transported between the LRCF and TACF; and the LRCF 
and SACF 

Figure 540 is a table representing the detail of an AUTHENTICATION CHALLENGE request indication and an 
AUTHENTICATION CHALLENGE response confirmation transported between the TACF and TACAF; and the 
SACF and MCF. 

Figure 541 is a table representing the detail of an AUTHENTICATION request indication and an AUTHENTICA- 
TION response confirmation. 

Figure 542 is a table representing the detail of a start ciphering IF transported between the TACF and TACAF; and 
the LRCF to TACF. 

Figure 543 is a table representing the detail of another start ciphering IF transported between the LRCF and SACF. 
Figure 544 is a table representing the detail of a TMUI ASSIGNMENT request indication and a TMUI ASSIGN- 
MENT response confirmation transported between the TACF and TACAF. 

Figure 545 is a table representing the detail of a TMUI QUERY request indication and a TMUI QUERY response 
confirmation. 

Figure 546 is a table representing the detail of a TMUI MODIFY request indication and a TMUI MODIFY response 
confirmation. 

Figure 547 is a table representing the detail of another TMUI ASSIGNMENT request indication and another TMUI 
ASSIGNMENT response confirmation transported between the LRCF to TACF. 

Figure 548 is a table representing the detail of another TMUI ASSIGNMENT request indication and another TMUI 
ASSIGNMENT response confirmation transported between the LRCF and SACF. 

Figure 549 is a table representing the detail of another TMUI ASSIGNMENT request indication and another TMUI 
ASSIGNMENT response confirmation transported between the SACF and MCF. 

Figure 550 is a table representing the detail of an IMUI RETRIEVAL request indication and an IMUI RETRIEVAL 
response confirmation transported between the LRCF and LRDF 

Figure 551 is a table representing the detail of another IMUI RETRIEVAL request indication and another IMUI 
RETRIEVAL response confirmation transported between the SACF and LRCF 

Figure 552 is a table representing the detail of another IMUI RETRIEVAL request indication and another IMUI 
RETRIEVAL response confirmation transported between the MCF and SACF. 

Figure 553 is a table representing the detail of another IMUI RETRIEVAL request indication and another IMUI 
RETRIEVAL response confirmation transported between the TACF and LRCF. 

Figure 554 is a table representing the detail of another IMUI RETRIEVAL request indication and another IMUI 
RETRIEVAL response confirmation transported between the TACAF and TACF 

Figure 555 is a table representing the detail of the service access point identifier in a layer 3 compatible sub-sub- 
layer PDU. 

Figure 556 is a table representing the detail of the ST in the layer 3 compatible sub-sub-layer PDU. 
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Figure 557 is a table representing the detail of the code type indicator in the layer 3 compatible sub-sub-layer PDU. 
Figure 558 is a table representing the detail of the reserved parameter in the layer 3 compatible sub-sub-layer PDU. 
Figures 559 and 560 form a table representing various types of LLC protocol data units (PDUs). 
Figure 561 is a table representing the relationship between the length of CRC fields in an MAC PDU and channels 
5 through which corresponding frame is transmitted. 

Figure 562 is a table representing the bit coding of the ST field in a layer 1 frame and the meaning thereof. 
Figure 563 is a table representing the bit coding of the Bl field in a layer 1 frame and the meaning thereof. 
Figure 564 is a table representing the bit coding of the uplink interference field in a layer 1 frame and the meaning 
thereof. 

10 Figure 565 is a table representing the relationship between the usage of the PID field in a layer 1 frame and the 
range of PID value. 

Figure 566 is a table representing the bit coding of the U/C field in a layer 1 frame and the meaning thereof. 
Figure 567 is a table representing the bit coding of the TN field in a layer 1 frame and the meanings thereof. 
Figure 568 is a table representing the bit coding of the MO field in a layer 1 frame and the meanings thereof. 
15 Figure 569 is a table representing the relationship between the length of CRC fields and channels through which 
corresponding frames are transmitted. 

Figure 570 is a list representing various messages belonging to CC (call/connection control) entity message. 

Figure 571 through 573 form a list representing information elements constituting an alerting message. 

Figure 574 through 576 form a list representing information elements constituting a call proceeding message. 
20 Figure 577 though 581 form a list representing information elements constituting a connect message. 

Figure 582 is a list representing information elements constituting a connect acknowledge message. 

Figures 583 through 585 form a list representing information elements constituting a progress message. 

Figures 586 through 594 form a list representing information elements constituting a setup message. 

Figure 595 is a list representing information elements constituting a release message. 
25 Figure 596 is a list representing information elements constituting a release complete message. 

Figure 597 is a list representing information elements constituting an information message. 

Figure 598 is a list representing a message (mobility facility message) belonging to the MM-T (terminal mobility 

management) entity message. 

Figure 599 is a list representing the generic formats of the mobility facility message. 
30 Figures 600 and 601 form a list representing information elements constituting a mobility facility message trans- 
ferred from a mobile station to the network for requesting terminal location registration. 

Figure 602 is a list representing information elements constituting a mobility facility message indicating "return * 
result" issued when the terminal location has been normally registered. 

Figure 603 is a list representing information elements constituting a mobility facility message indicating "return 

35 error" issued when an abnormality, for example, an application error has occurred. 

Figure 604 is a list representing information elements constituting a mobility facility message indicating "return 
error" when an abnormality, for example, a discrepancy of an information element has occurred. 
Figure 605 is a list representing information elements constituting a mobility facility message transferred for notify- 
ing a mobile station of the TMUI allocated to the mobile station. 

40 Figure 606 is a list representing information elements constituting a mobility facility message indicating "return 
result" issued when the TMUI has been normally assigned. 

Figure 607 is a list representing information elements constituting a mobility facility message indicating "return 
error" issued when an abnormality, for example, an application error has occurred. 

Figure 608 is a list representing information elements constituting a mobility facility message indicating "return 
45 error" when an abnormality, for example, a discrepancy of an information element has occurred. 

Figures 609 and 610 form a list representing information elements constituting a mobility facility message trans- 
ferred from the network to a mobile station for authenticating the mobile station by the mobile service switching 
center. 

Figure 611 is a list representing information elements constituting a mobility facility message indicating "return 
so result" issued when the authentication has been normally requested. 

Figure 612 is a list representing information elements constituting a mobility facility message indicating "return 
error" issued when an abnormality, for example, an application error has occurred. 

Figure 613 is a list representing information elements constituting a mobility facility message indicating "return 
error" when an abnormality for example, a discrepancy of an information element has occurred. 
55 Figure 61 4 is a list representing information elements constituting a mobility facility message transferred for notify- 
ing a mobile station of ciphering onset 

Figure 615 is a list representing information elements constituting a mobility facility message indicating "return 
result" issued when the ciphering onset has been normally notified. 
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Figure 616 is a list representing information elements constituting a mobility facility message indicating "return 
error" issued when an abnormality, for example, an application error has occurred. 

Figure 617 is a list representing information elements constituting a mobility facility message indicating "return 
error" when an abnormality for example, a discrepancy of an information element has occurred. 
5 Figure 618 is a list representing information elements constituting a mobility facility message transferred for inquir- 
ing of a mobile station as to the IMUI of the mobile station. 

Figure 619 is a list representing information elements constituting a mobility facility message indicating "return 
result' issued when the IMUI has been normally inquired. 

Figure 620 is a list representing information elements constituting a mobility facility message indicating "return 
10 error" issued when an abnormality, for example, an application error has occurred. 

Figure 621 is a list representing information elements constituting a mobility facility message indicating "return 

error" when an abnormality for example, a discrepancy of an information element has occurred. 

Figure 622 is a list representing messages belonging to RBC entity message. 

Figure 623 is a list representing classification of RBC entity message. 
15 Figure 624 is a list represent ng the format of radio bearer setup message. 

Figure 625 is a list representing the format of radio bearer release message. 

Figure 626 is a list representing the format of radio bearer release complete message. 

Figure 627 is a list representing the format of handover command message. 

Figure 628 is a list representing the format of handover response message. 
20 Figure 629 is a list representing a message (radio resource facility message) belonging to RRC entity message. 

Figure 630 is a list representing the format of the RRC facility message. 

Figure 631 is a list representing TAC entity messages. 

Figure 632 is a list representing the relationship between TAC entity message and information flow. 
Figure 633 is a list representing the format of a terminal association setup message. 
25 Figure 634 is a list representing the format of a terminal association connect message. 

Figure 645 is a list representing the bit coding manner of a protocol discriminator in the CC entity message. 
Figures 646 and 647 form a list representing the bit coding manner of a message type identifier. 
Figures 648 and 649 form a list representing the bit coding manner of a variable length information element accord- 
ing to FPLMTS. 

30 Figure 650 is a list representing the bit coding manner of a broadband locking shift information element. 

Figure 651 is a list representing the bit coding manner of a broadband non-locking shift information element. 
Figures 652 through 654 form a list representing the bit coding manner of an AAL parameter information element. 
Figure 655 is a list representing the bit coding manner of an ATM traffic descriptor information element. 
Figure 656 is a list representing the bit coding manner of a broadband bearer capability information element. 

35 Figure 657 is a list representing the bit coding manner of a broadband high layer information element. 

Figures 658 through 660 form a list representing the bit coding manner of a broadband low layer information ele- 
ment. 

Figure 661 is a list representing the bit coding manner of a called party number information element. 

Figure 662 is a list representing the bit coding manner of a called party sub-address information element. 
40 Figures 663 and 664 form a list representing the bit coding manner of a calling party number information element. 

Figure 665 is a list representing the bit coding manner of a calling party sub-address information element. 

Figure 666 is a list representing the bit coding manner of a connection identifier information element. 

Figure 667 is a list representing the bit coding manner of an end-to-end transit delay information element. 

Figure 668 is a list representing the bit coding manner of a QOS parameter information element. 
45 Figure 669 is a list representing the bit coding manner of a broadband repeat indicator information element. 

Figure 670 is a list representing the bit coding manner of a transit network selection information element. 

Figure 671 is a list representing the bit coding manner of an OAM traffic descriptor information element 

Figure 672 is a list representing the bit coding manner of an MM-T specific information elements. 

Figure 673 is a list representing parameters of a candidate zone information for call attempt or acceptance. 
so Figure 674 is a list representing parameters of an in-use zone information. 

Figure 675 is a list representing parameters of an added zone information for DHO. 

Figure 676 is a list representing parameters of a deleted zone information for DHO. 

Figure 677 is a list representing parameters of a HHO zone information. 

Figure 678 is a list representing parameters of an outer loop information. 
55 Figure 679 is a list representing parameters of a quality deterioration notification information. 

Figure 680 is a list representing the bit coding manner of a TAC entity message. 

Figure 681 is a list representing TAC entity message specific parameters. 

Figure 682 is a list representing the bit coding manner of a terminal association setup message specific parameter. 
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Figure 683 is a list representing the bit coding manner of a paging response message specific parameter. 
Figure 684 is a list representing the bit coding manner of a terminal association release message specific param- 
eter. 

Figure 685 is a list representing information elements which may be contained in subfields of TAC entity message 
5 specific parameters. 

Figure 686 is a list representing the bit coding manner of a cause information element. 

Figure 687 is a list representing the bit coding manner of a mobile station type information element. 

Figure 688 is a list representing the bit coding manner of a paged MS ID information element. 

Figure 689 is a list representing the bit coding manner of a paging ID information element. 
10 Figure 690 is a list representing types of BC entity messages. 

Figure 691 is a list representing a classification of BC entity messages. 

Figure 692 is a list representing structural information elements of a link setup requested message. 
Figure 693 is a list representing structural information elements of a link setup message. 
Figure 694 is a list representing structural information elements of a link setup proceeding message. 
is Figure 695 is a list representing structural information elements of a link setup response message. 

Figure 696 is a list representing structural information elements of a link facility message sent from the MSCNW to 
the BTS. 

Figure 697 is a list representing structural information elements of another link facility message sent from the BTS 
to the MSCNW. 

20 Figure 698 is a list representing structural information elements of a link release message. 

Figure 699 is a list representing structural information elements of a link release complete message. 
Figure 700 is a list representing the combinations of the fundamental information elements in the link setup mes- 
sage in various uses. 

Figure 701 is a list representing the combinations of the fundamental information elements in the link setup pro- 
25 ceeding message in various uses. 

Figure 702 is a list representing the combinations of the fundamental information elements in the link setup 
response message in various uses. 

Figure 703 and 704 form a list representing the combinations of the fundamental information elements in the link 
facility message in various uses. 
30 Figure 705 and 706 form a list representing the combinations of the fundamental information elements in the other 
link facility message in various uses. 

Figure 707 is a list representing a message belonging to the BSM entity message. 
Figure 708 is a list representing structural information elements of a paging message. 
Figure 709 is a list representing the format of a link ID information element. 
35 Figure 710 is a list representing the format of a TCH setup request information element without frequency indica- 
tion. 

Figure 71 1 is a list representing the format of a TCH setup request information element without frequency indica- 
tion. 

Figure 712 is a list representing the format of a TCH setup request information element with frequency indication. 
40 Figure 713 is a list representing the format of a DHO branch addition request information element. 

Figure 714 is a list representing the format of an intra-BS DHO branch addition request information element. 
Figure 715 is a list representing the format of an ACCH setup request information element. 
Figure 71 6 is a list representing the format of a TCH setup acceptance information element without frequency indi- 
cation. 

45 Figure 71 7 is a list representing the format of a TCH setup acceptance information element without frequency indi- 
cation. 

Figure 718 is a list representing the format of a TCH setup acceptance information element with frequency indica- 
tion. 

Figure 719 is a list representing the format of a TCH setup response information element without frequency indica- 
so tion. 

Figure 720 is a list representing the format of a TCH setup response information element without frequency indica- 
tion. 

Figure 721 is a list representing the format of a TCH setup response information element with frequency indication. 
Figure 722 is a list representing the format of a DHO branch addition response information element. 
55 Figure 723 is a list representing the format of an intra-BS DHO branch addition response information element 
Figure 724 is a list representing the format of an ACCH setup response information element. 
Figure 725 is a list representing the format of an intra-BS DHO branch addition request information element. 
Figure 726 is a list representing the format of an intra-BS DHO branch deletion request information element. 
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Figure 727 is a list representing the format of an intra-BS HHO branch addition request information element. 
J Figure 728 is a list representing the format of an ACCH release request information element. 

Figure 729 is a list representing the format of a frequency replacement setup request information element without 
frequency indication. 

5 Figure 730 is a list representing the format of a frequency replacement setup request information element with fre- 
quency indication. 

Figure 731 is a list representing the format of a setup completion notification information element. 
Figure 732 is a list representing the format of an intra-BS HHO branch deletion response information element. 
Figure 733 is a list representing the format of an intra-BS HHO branch addition response information element. 
10 Figure 734 is a list representing the format of an ACCH release response information element. 

Figure 735 is a list representing the format of a frequency-indicated frequency replacement setup response infor- 
mation element. 

Figure 736 is a list representing the format of a frequency-indicated frequency replacement setup request informa- 
tion element. 

is Figure 737 is a list representing the format of a frequency-non-indicated frequency replacement setup acceptance 
information element. 

Figure 738 is a list representing the format of a frequency-non-indicated frequency replacement setup response 
information element. 

Figure 739 is a list representing the format of a code replacement request information element. 
20 Figure 740 is a list representing the format of a TCH release request information element. 

Figure 741 is a list representing the format of an SDCCH release request information element. 

Figure 742 is a list representing the format of a cause information element. 

Figure 743 is a list representing the format of an SDCCH setup request information element. 

Figure 744 is a list representing the format of an LAI setup request information element. 
25 Figure 745 is a list representing the format of a protocol discriminator of a BC entity message. 

Figure 746 is a list representing the format of a message type identifier of a BC entity message. 

Figure 747 is a list representing the format of a protocol discriminator of a BSM entity message. 

Figure 748 is a list representing the format of a message type identifier of a BSM entity message. 

Figure 749 is a list representing the format of a number type parameter indicating the type of number which is 
30 included at octet 4 and later octets in the paged MS ID shown in Figure 252. 

Figure 750 is a list representing the format of a number length parameter indicating the length of number which is 

included at octet 4 and later octets in the paged MS ID shown in Figure 252. 

Figure 751 is a block diagram showing a part of the mobile communications system in which a signal is ciphered 
and successfully received. 

35 Figure 752 is a block diagram similar to Figure 751 , but the ciphered signal is not successfully received. 

Figure 753 is a block diagram showing a part of the mobile communications system for the description of an enci- 
pherment procedure. 

Figure 754 is a block diagram representing the operation of the encipherment procedure in the invented system. 
Figure 755 is a ciphering procedure sequence diagram in normal operation where the network and the mobile sta- 
40 tion commence to encipher transmitted signals and to decipher received signals after transmission of an encipher- 
ing onset request from the network to the mobile station. 

Figure 756 is a sequence diagram representing a disadvantage of the ciphering procedure sequence represented 
in Figure 755. 

Figure 757 is a ciphering procedure sequence diagram in normal operation according to a control method 
45 described in section 3. 1 . 

Figure 758 is a sequence diagram representing an advantage of the ciphering procedure sequence according to a 
control method described in section 3.1 . 

Figure 759 is a schematic sequence diagram representing an encipherment method in a mobile communications 
system, in which only a specific encipherment manner is adopted. 
so Figure 760 represents a schematic sequence diagram representing a selection of encipherment manner by nego- 
tiation between mobile station and network in accordance with a control method described in section 3.2. 
Figures 761 and 762 constitute a detailed sequence diagram representing the control method described in section 
3.2. 

Figure 763 is a diagram representing a conventional method for establishing access link for a mobile station when 
55 the mobile station locates at a position where intra-cell diversity handover can be carded out 

Figure 764 is a diagram representing a conventional method for establishing access link for a mobile station when 

the mobile station locates at a position where inter-cell diversity handover can be carried out. 

Figure 765 is a sequential flow diagram representing a series of information flows transported between the mobile 
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station and the network for carrying out the access link setup procedure. 

Figure 766 is a sequential flow diagram representing a series of information flows transported between the mobile 
station and the network for entering the intra-cell diversity handover procedure. 

Figure 767 is a sequential flow diagram representing a series of information flows transported between the mobile 
5 station and the network for entering the intra-cell diversity handover procedure. 

Figure 768 is a diagram representing features of the invented system for starting diversity handover simultaneously 
with the access link setup. 

Figure 769 is a sequential flow diagram representing the start of intra-cell diversity handover simultaneously with 
the access link setup. 

w Figure 770 is a sequential flow diagram representing the start of inter-cell diversity handover simultaneously with 
the access link setup. 

Figure 771 is a diagram representing a situation where transition to diversity handover is necessary immediately 
after the completion of branch replacement. 

Figure 772 is a sequential flow diagram representing a series of information flows transported between the mobile 
15 station and the network for carrying out the branch replacement. 

Figure 773 is a sequential flow diagram representing an operation in the invented system which is carried out when 
the mobile station moves to a diversity handover zone. 

Figure 774 is a diagram representing an embodying method for controlling branch structure and frequency band in 

the system according to the presented invention when a call attempt occurs to or from a mobile station that can 
20 treats a plurality of calls simultaneously and is treating a call. 

Figure 775 is a sequential flow diagram representing the operation exemplified in Figure 774 of the system. 

Figure 776 is a diagram representing another embodying method for controlling branch structure and frequency 

band in the system according to the presented invention when a call attempt occurs to or from a mobile station that 

can treats a plurality of calls simultaneously and is treating a call. 
25 Figure 777 is a diagram representing another embodying method for controlling branch structure and frequency 

band in the system according to the presented invention when a call attempt occurs to or from a mobile station that 

can treats a plurality of calls simultaneously and is treating a call. 

Figure 778 is a sequential flow diagram representing the operation exemplified in Figure 776 of the system. 
Figure 779 is a sequential flow diagram representing the operation exemplified in Figure 777 of the system. 

30 Figure 780 is a diagram representing a control method executed in the system according to the present invention 
when a trigger of handover occurs to the mobile station which is treating a plurality of calls. 
Figure 781 is a diagram representing another control method executed in the system according to the present 
invention when a trigger of handover occurs to the mobile station which is treating a plurality of calls. 
Figure 782 is a sequential flow diagram representing the operation exemplified in Figure 780 of the system. 

35 Figure 783 is a sequential flow diagram representing the operation exemplified in Figure 781 of the system. 

Figure 784 is a diagram representing another control method executed in the system according to the present 
invention when a trigger of handover occurs to the mobile station which is treating a plurality of calls. 
Figure 785 is a sequential flow diagram representing the operation exemplified in Figure 784 of the system. 
Figure 786 is a sequential flow diagram representing an operation for the start of inter-cell diversity handover simul- 

40 taneously with the access link setup. 

Figure 787 is a flowchart of an operation of the mobile station, which is appropriate to realizing the operation in Fig- 
ure 786. 

Figure 788 is a sequential flow diagram representing a conventional operation for access link setup for a mobile sta- 
tion when the mobile station is located at the position where it can carry out intra-cell diversity handover. 

45 Figure 789 is a flowchart of an operation of the mobile station for realizing the operation in Figure 786. 
Figure 790 is a diagram showing a part of the invented system for describing the ACCH replacement. 
Figure 791 is a sequential diagram representing an alteration of the ACCH replacement procedure, similar to that 
shown in Figures 53 and 54, but is not accompany with the replacement of wired access link. 
Figure 792 is a diagram for describing the uplink transmission power control for the mobile stations in the invented 

so system. 

Figure 793 and 794 are diagrams representing a method for reassigning code resources in section 3.10. 
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BEST MODE FOR CARRYING OUT INVENTION 

1 . GENERAL DESCRIPTION OF SYSTEM 

5 1.1. INTRODUCTION 

[01 1 2] This system is a mobile communications system wherein W-CDMA(wide-band code division multiple access) 
is adopted for the radio access manner in order to enhance efficiency for frequency utilization, to process multiplexed 
and high-rate signals flexibly, and to improve the communication quality to the level equivalent to fixed networks. 

10 

1.2 ENTIRE SYSTEM STRUCTURE 

[0113] First, with reference to Figure 1, the entire structure of a W-CDMA mobile communications system in accord- 
ance with an embodiment of the present invention will be described. As shown in Figure 1, the system comprises 

15 mobile stations MS and a radio base station system BSS. The base station system BSS is constituted of base trans- 
ceiver systems BTS and a mobile communications control center MCC connected to the base transceiver systems via 
cable transmission lines HW. The mobile stations MS include a wide-purpose mobile station, a small portable mobile 
station 2 connected to a personal computer, a small portable mobile station 3 that is a traditional portable telephones, 
and so on. The mobile communications control center MCC is connected with the personal computers via a fixed PSTN 

20 or ISDN, telephone network, or LAN. With such a structure, high-quality voice data, N-ISDN, packets or modem signals 
may be transformed. 

1.3 ABBREVIATIONS 

25 [01 14] Glossary of the abbreviations used in the present specification is indicated in Figure 265. In addition, the tech- 
nical terms, which are used in the present specification but not defined, comply with ITU-T Recommendation Q.65. 

2. ACCESS INTERFACES 

30 2.1 GENERAL DESCRIPTION OF ACCESS INTERFACES 

[01 1 5] Chapter 2 prescribes access interfaces of W-CDMA mobile communications system. The access interfaces in 
this system include, as shown in Figure 2, a radio interface served for communication between the mobile station MS 
and the base transceiver systems BTS, and a BTS-MCC interface served for communication between the base trans- 
35 ceiver systems BTS and the mobile communications control center MCC. Although this specification describes the W- 
CDMA mobile communications system to enable any person skilled in the art to make or use the present invention, the 
present invention is not intended to be limited to the described W-CDMA mobile communications system, but is 
intended to cover any mobile communications system according to any kind of access manner within the attached 
claims. 

40 [01 1 6] To prescribe the interfaces, this chapter includes the following items: 

1) Services Provided by the System and the System Capabilities in Compliance with the Protocols 

2) System Functional Structure and Control Manners for Realizing the Services and System Capabilities 

3) Rules for Reference Model Structure and Interfaces in Compliance with the Protocols 
45 4) Physical Architecture and Physical Condition of the Radio Interface 

5) Signal Transfer Protocol for the Radio Interface (Layer-2) 

6) Control Protocol for the Radio Interface (Layer-3) 

7) Physical Architecture and Electrical Condition of the BS-MCC Interface 

8) Information Transmission Protocol for the BS-MCC Interface (ATM Layer and AAL type-2) 
so 9) Signal Transfer Protocol for the BS-MCC Interface (AAL) 

10) Control Protocol for the BS-MCC Interface (Layer-3) 

[01 1 7] The control manners and protocol specifications described in this chapter comply with recommendation drafts 
Q.FNA, Q.FIF, Q.FSA, and Q.FSR prepared on the basis of the discussions at TTC IMT-2000 Study Committee. Net- 
55 work Aspect ad hoc. 
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2.2 FEATURES OF ACCESS INTERFACES 

[01 18] Next, features of access interfaces will be described. 

5 2.2.1 HANDOVER 

(0119] A plurality of radio zones are arranged in a mobile communications system and each zone is provided with 
abase station. To start communication between one of the base stations and a mobile station, a kind of wireless channel 
called a perch channel is employed. More specifically, a plurality of perch channels of which the frequency bands are 
w different from each other are established between the base station and the mobile station for selecting one of traffic 
channels for actual communication. That is to say, the traffic channel TCH for transporting voice or messages is 
selected by virtue of the perch channels. 

[0120] When a mobile station MS travels across the boundary of radio zones, lowered is the level of the electric field 
of the radio wave received from the base station of the zone from which the mobile station has exited, thereby depreci- 
15 ating the communication quality. Accordingly, it is necessary for the mobile station to after the currently communicating 
base station to a new base station from which the reception is more excellent, so that the traffic channel TCH employed 
by the mobile station MS is replaced. This replacement is called handover. 

[0121] In order to facilitate handover, it is preferable that the frequency band of the former traffic channel TCH and 
that of the new traffic channel TCH are the same with each other. In accordance with traditional mobile communications, 
20 a mobile station MS measures the respective levels of the electric fields of in relation to circumferential perch channels 
and selects candidate base stations for handover. The mobile station then informs the network of a handover request 
designating the candidate base stations for handover. 

[01 22] However, if the traffic channel TCH of the same frequency band as that of the currently communicating channel 
is not preselected for candidate cells in circumferential zones, it is impossible that the cells serve the mobile station 
25 although the mobile station has transmitted the handover request. Therefore, it is necessary for the network to exclude, 
from the candidate cells, the cell without preselection of traffic channel TCH of the same frequency band as that of the 
currently communicating traffic channel in accordance with the prior art. 

[0123] Accordingly, in the present system, the mobile station MS sends the network a handover request wherein pre- 
viously excluded is the cell that does not preselect the traffic channel TCH at the same frequency band as the current 

so communication. Next, this feature will be described with reference to Figure 259 in more detail. 

[0124] Figure 259 represents an example of handover procedure in the present communications system. In Figure 
259, a mobile station MS is communicating at a frequency band f2 in a zone 1. Assume the mobile station MS travels 
from zone 1 to zone 2; and strength ranking of the reception level (level of the electric field of the received wave) meas- 
ured by the mobile station MS at the frequency band f2 is zone 2, zone 3, and zone 4. In this case, the traditional hando- 

35 ver request designates that the primary candidate zone is zone 2, the secondary candidate is zone 3, and the third 
candidate is zone 4. 

[0125] On the contrary, according to the present communications system, broadcasting information indicating the 
preselection condition of the traffic channels TCH with reference to the respective circumferential zones is informed to 
the mobile station MS as will be described at section 2.5.2.4.2.6. Using the broadcasting information, the mobile station 
40 recognizes the zone in which the traffic channel TCH at the same frequency band as the current communication is not 
preselected, so as to exclude the recognized zone from the handover candidates. Therefore, the mobile station MS in 
the embodiment informs the network of the handover request designating that the primary candidate zone is zone 3 and 
the secondary candidate is zone 4. 

[01 26] As will be described in section 2.3.2.2.4, the present communications system can carry out a handover branch 
45 addition, handover branch deletion, and branch replacement handover. The above-discussed procedure in view of the 
preselection status of traffic channel may be carried out at the handover branch addition and the branch replacement 
handover. 

[0127] With reference to Figure 37, description will be given with respect to an example of sequential operation 
wherein the mobile station MS completes to request handover. In Figure 37, MRRC, MRTR, RFTR, and RRC designate 
so functional entities arranged in the mobile station MS. MRRC controls the radio resources. MRTR controls an encipher- 
ment procedure and outputting procedure and measures the radio environment, that is, the respective reception levels 
in relation to the circumferential radio zones. RFTR controls an encipherment procedure and outputting procedure. 
RRC controls the radio resources. 

[0128] As shown in Figure 37, MRRC provides a CELL CONDITION MEASUREMENT request indication indicating 
55 a request for measurement of the wireless environment to MRTR at periodic intervals. Upon the reception of it, MRTR 
measures the respective reception levels in relation to the circumferential radio zones and transmits MRRC the meas- 
urement result as a CELL CONDITION MEASUREMENT response confirmation. Next MRRC compares the reception 
level of the currently communicating wireless channel with the reception levels of the wireless channels from the circum- 
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ferential zones. If the latter is stronger than the former, MRRC conducts the following process to execute handover. 
[0129] MRRC excludes the zone to which the traffic channel is not preselected on the basis of the broadcast informa- 
tion, and ranks the zones in strength order with reference to the same frequency band as the current communication. 
Then, MRRC rearranges the remaining zones in order of strength rank, the remaining zones being the candidates for 
5 handover; generates a NON-SOFT HANDOVER EXECUTION TRIGGER request indication designating the strength 
order of the remaining zones; and sends the NON-SOFT HANDOVER EXECUTION TRIGGER request indication to 
TACF in the network via RRC. 

[0130] The notification of non-soft handover execution trigger requirement to TACF triggers the handover. Then, the 
network selects the base station among the candidate base stations in order to execute the handover and notifies the 
10 mobile station MS about the selected base station, thereby activating the traffic channel in relation to the base station. 
Accordingly, it is possible for the network to exclude complicated control procedures, e.g., detection procedure of the 
frequency band that the mobile station MS uses for communication and determination procedure as to whether the traf- 
fic channel TCH of the same frequency band is preselected by the candidate zone or not. Subsequent operation follow- 
ing the handover trigger is illustrated in Figure 49. 

15 

2.2.2 REPLACEMENT OF ACCH 

[0131] Associated control channel (ACCH) is a kind of control channel utilizing the same radio resources as those for 
the traffic channel TCH that is used for voice or data transportation. By means of ACCH, control signals may be trans- 

20 ported between the mobile station MS and base station BS. 

[0132] There is a kind of communications system wherein one mobile station MS can treat a plurality of calls simul- 
taneously. In addition, there is another kind of communications system wherein one mobile station MS realizes a call 
using a plurality of radio physical channels. These systems are suitable for radio bearer services. In these kinds of sys- 
tems, sometimes it is necessary that control signals may be transported between the mobile station MS, which is treat- 

25 ing the plurality of calls, and base station BS. 

[0133] For this purpose, it would be possible to form ACCHs corresponding to all of the plurality of calls for transport- 
ing control signals, ACCHs being constituted of wireless communication resources which are also utilized by the traffic 
channels. However, this technique needs many hardware elements for transporting control signals and complicated 
control procedures for managing the transportation order of control signals in the plurality of ACCHs. 

30 [0134] Accordingly, in the present communications system, when the mobile station treats a plurality of calls using a 
plurality sets of wireless communication resources which are also being utilized by a plurality of traffic channels, one set 
of the wireless communication resources is selected and then the control channel, which uses this set, is established 
between the mobile station and the base station for transporting the control information therebetween. 
[0135] The method for establishing ACCH in the communications system will be described next in more detail. 

35 [01 36] Figure 260 illustrates an example of mobile communications system wherein a mobile station treats a plurality 
of calls. In Figure 260. traffic channels respectively corresponding to the plurality of calls are established between a 
mobile station MS and a base station BS, whereby the calls can be treated simultaneously. For treating the multiple 
calls, only one ACCH (e.g., ACCH1 in Figure 260) is selected from the multiple ACCHs corresponding to multiple traffic 
channels, and shared for transporting all control signals in relation to the mobile station in the system. 

40 [0137] Therefore, by virtue of the system, it is possible to reduce the number of hardware elements for transporting 
control signals in comparison with the case that all of the plurality of calls respectively utilize multiple ACCHs, corre- 
sponding to the multiple traffic channels. In addition, it is possible to exclude complicated control procedures, e.g., man- 
agement of the transportation order of control information in the plurality of ACCHs. 

[01 38] In the system shown in Figure 260, however, when a set of wireless communication resources involved in the 
45 single ACCH is released due to the release of one of the traffic channels by the ending of the call, it is difficult to secure 
the ACCH to continue the other calk The same problem may occur when the transmission rate in the ACCH is altered. 
[0139] Accordingly, in addition to sharing the single ACCH by the multiple traffic channels for realizing the multiple 
calls simultaneously by the single mobile station MS, when the single set of wireless communication resources involved 
in the single ACCH is released, the ACCH is replaced by another ACCH. Figure 261 illustrates functional entities to real- 
so ize the ACCH replacement of the system. In this illustration, the mobile station MS treats two calls, namely first call and 
second call, simultaneously, the first and second calls utilizing the traffic channel TCH1 or TCH2 respectively. However, 
only one associated control channel ACCH1 is served for transporting control information between the network and the 
mobile station MS in an initial state. 

[0140] As shown in Figure 261 , the mobile station MS includes functional entities called TACAF, BCAF1 , and BCAF2. 
55 TACAF controls the access and instructs to release and establish the ACCHs. BCAF1 controls the radio bearer for the 
first call while BCAF2 controls the radio bearer for the second call. BACF1 and BACF2 execute to release and establish 
the corresponding ACCHs, respectively. 

[0141] The base station BS includes functional entities called BCFrl and BCFr2 while the network includes a func- 
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tional entity called TACF which functions as a base station controller (BSC). BCFrl and BCFr2 respectively control the 
radio bearers for the first and second calls and execute to activate and release the corresponding ACCHs. TACF con- 
trols the access and instructs to activate and release the ACCHs. 

[0142] Assume that the second call utilizing the traffic channel TCH2 should be continued while the first call utilizing 
5 the traffic channel TCH 1 is ended. The ACCH replacement procedure will be described in the sequential diagram in Fig- 
ure 262. 

[0143] In the procedure, first, once the first call utilizing the traffic channel TCH1 is ended, the traffic channel TCH1 
is released. Once TACF detects the release trigger of the traffic channel TCH1, TACF determines whether ACCH1 on 
the same physical channel as the traffic channel TCH1 is used or not. In addition, TACF determines whether an ACCH 

to is necessary for continuing the traffic channel TCH2 although the traffic channel TCH1 is released. 

[0144] If those determinations are affirmative, TACF sends BCFr2, which is in charge of the second call, an activation 
request for ACCH2 that is accompanying with the traffic channel TCH2. In response, BCFr2 activates ACCH2. Then, 
BCFr2 sends a completion report indicating the completion of the activation of ACCH2 to TACF. 
[0145] Upon the completion report, TACF informs TACAF of a replacement request for switching to ACCH2. The 

is reception of the replacement request causes TACAF to inform BACF2 of an establishment request for ACCH2, so that 
BCAF2 establishes ACCH2. Additionally, TACF informs BCAF1 of a release requirement for ACCH1 so that BCAF1 
releases ACCH1. 

[0146] Next, TACAF sends TACF a replacement completion report indicating the completion of the replacement of 
ACCH. Then, TACF informs BCFrl of a request for releasing ACCH1 , so that BCFrl releases ACCH. Consequently, the 
20 ACCH replacement is completed, so that transportation of control information between the mobile station and the net- 
work may be accomplished via ACCH2, which uses the same radio resources as the traffic channel TCH2. The ACCH 
replacement procedure will be described again in more detail at section 2.4.3.5.7. 
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2.2.3 PROCEDURES FOR ENCIPHERMENT ONSET MOMENT NOTIFICATION 



[0147] Since mobile communications are carried out over the air, signals are sometimes ciphered (encoded into 
cipher) at the source terminal to be preserved from intercept or manipulation by a third party. The destination terminal 
deciphers the ciphered signals (decodes them to make out the meaning). 

[0148] However, in communication of the enciphered signals (control signals), if the onset moment of the encipher- 
30 ment is unclear, it is impossible to decipher smoothly. That is, if the onset time of the decipherment may be misesti- 
mated, the meaning of signals cannot be made out. 

[0149] With reference to Figures 751 and 752, a trouble occurring in relation to timing error of encipherment onset 
and decipherment onset will be described. 

[0150] Figure 751 represents a mobile communications system in which an encipherment transfer is conducted. 

35 Assume that a mobile station MS can receive signals using a diversity handover technique. As illustrated in Figure 751 , 
a base station controller RNC distributes the same series of transmission signals (non-enciphered signals) to a plurality 
of radio base stations BS1 to BS3 for diversity handover of the mobile station. Then, the radio base stations BS1 to BS3 
enciphers the series of signals and transmits the enciphered signals to the single mobile station MS. 
[0151 ] In this system, since the respective base stations execute the encipherment processes, there is likelihood that 

40 the onset moment of the encipherment varies among the base stations. It is possible in theory to align the encipherment 
onset moment among the base stations, but difficult in practice. More specifically, the base station controller RNC 
should negotiate with the radio base stations BS1 to BS3 in advance for matching the encipherment onset time. How- 
ever, it is difficult in practice to prevent the timing error completely. 

[0152] As described above, it is necessary that the same kind of signal (i.e., enciphered transmission signal or non- 
45 enciphered transmission signal) should be transmitted from all of the base stations BS1 to BS3 for realizing the diversity 
combining at the mobile station. However, layer 1 of the OSI reference model supervises between the mobile station 
and the respective base stations although layer 3 supervises between the mobile station MS and the base station con- 
troller RNC or between the mobile station MS and the mobile service switching center MSC. 
[0153] Accordingly, as shown in Figure 752, if the encipherment is conducted for Layer 1 of the OSI reference model, 
so a group of base stations (e.g., BS2 and BS3) transmit enciphered signal while another group of the base stations (e.g., 
BS1) transmit non-enciphered signal at the same time. Therefore, it is impossible for a type of mobile station, which can- 
not process in parallel the enciphered signal and non-enciphered signal in view of structure simplification and produc- 
tion-cost reduction, to conduct diversity combining. 

[0154] Therefore, it is an object to provide a communications system wherein even a type of mobile station, which 
55 cannot process in parallel an enciphered signal and non-enciphered signal, can carry out diversity reception securely. 
In the system, the mobile station MS and the mobile communications control center MCC mutually inform of the enci- 
pherment moment so as to appropriately decipher for errorless communication. 

[0155] With reference to the functional model in Figure 64, the encipherment onset moment notification procedures 
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will be described. As shown in Figure 64, the mobile station MS includes functional entities called UIMF, MCF, and 
TACAF. UIMF stores information on the station user and serves the user authentication and encipherment calculation. 
MCF functions as an interface with the network for realizing services that are not related to calls. TACAF controls the 
access processes to the mobile station terminal, e.g., the origination, paging, and so on. 
5 [0156] The network on the other hand includes functional entities called SACF, TACF, LRCF, and LRDF. SACF is con- 
nected with MCF to function as an interface with the mobile terminal for realizing services that are not related to calls. 
TACF is connected with TACAF to control the access processes to the mobile station terminal, e.g., the origination, pag- 
ing, and so on. LRCF is connected with TACF and SACF to control mobility management. LRDF stores various data on 
mobility management. 

10 [0157] With such a structure, prior to the mutual notification of the encipherment onset, a user authentication proce- 
dure (refer to section 2.4.5.1) is executed as shown in Figure 63. In execution of the user authentication procedure, a 
certificated encipherment key is previously stored at UIMF and LRDF of the network and mobile terminal and delivered 
to TACAF, MCF, TACF, and SACF. 

[0158] Then, mutual notification of the encipherment onset time is carried out in accordance with the sequence shown 
15 in Figure 65. More specifically, first, LRCF of the network sends a START CIPHERING request indication for indicating 

that the network will start encipherment to TACAF and MCF of the mobile terminal via TACF and SACF of the network. 

Consequently, the mobile terminal can recognize that the succeeding signals transmitted from the network will be 

ciphered. After the transmission of the START CIPHERING request indication, TACF and SACF of the network cipher 

succeeding signals according to a preselected encipherment procedure using a preselected ciphering key. Once the 
20 mobile terminal receives the enciphered signal, TACAF and MCF controls the decipherment of the received signals. In 

advance to the decipherment, TACAF and MCF receive the encipherment key from UIMF to carry out the decipherment. 

Accordingly, the downlink signal transmitted from the network can be transported in secret and interpreted by only the 

mobile terminal. 

[0159] Next, TACAF and MCF of the mobile terminal send a START CIPHERING response confirmation to TACF and 
25 SACF of the network, this confirmation indicating that mobile station will next start to transmit enciphered signals. Con- 
sequently, the network entities can recognize that the succeeding signals transmitted from the mobile terminal will be 
ciphered. After the transmission of the START CIPHERING response confirmation, TACAF and MCF of the mobile ter- 
minal cipher succeeding signals according to a preselected encipherment procedure using a preselected ciphering key. 
Once the terminal entities receive the enciphered signal, TACF and SCF decipher the received signals. Accordingly, the 
30 uplink signal transmitted from the mobile terminal can be transported in secret and interpreted by only the network. 
[0160] Next, it will be discussed which kind of information should be ciphered. In the invented system, the source 
device can freely decide the information to be ciphered as long as the destination device is notified of the ciphered infor- 
mation and communications at layers 1 through 3 are established. 

[0161] It is known that open system interconnection protocols should be adapted to the open system interconnection 
35 reference model illustrated in Figure 263. The OSI model defines the hierarchy consisting of seven functional layers for 
managing various functions from physical interconnection to application. 

[01 62] The lowest layer, layer 1 is called the physical layer. The physical layer prescribes mechanical or electrical pro- 
cedures or means, for example, configurations of connection plugs. 

[0163] Layer 2, datalink layer operates to establish, maintain, and release an individual data link and to detect and 
40 recover the error occurring in the physical layer. 

[0164] Layer 3, network layer sets up and manages an end-to-end connection between different networks, whereby 

the upper layers can proceed their respective functions without processing for the network type. 

[0165] Layer 4, transport layer controls the transparent end-to-end data relaying service between session entities. 

[0166] Layer 5, session layer establishes or releases the session connection. 
45 [0167] The sixth or presentation layer negotiates agreeable technique for data encoding and punctuation. 

[0168] The seventh or application layer identifies the communicating source and instructs the service quality. 

[0169] The international telecommunication union (ITU) scribes the line circuit interface at layer 3 that corresponds to 

layers 3 through 7 in the OSI reference model. 

[0170] The relationship of the OSI reference model and the present system will be described in more detail with ref- 
so erence to Figure 753. Figure 753 is a general view of the present system. 

[0171] The system illustrated in Figure 753 includes a mobile station MS, a plurality of radio base stations BS com- 
municable with the mobile station MS over the air, an base station controller RNC for controlling the base stations BS, 
and a mobile service switching center MSC for connecting the base station controller RNC with a fixed network. In addi- 
tion, the system meets the following conditions: 



55 



i) Both of the mobile station MS and the base station controller RNC can carry out diversity reception and distribu- 
tion. 

ii) Layer 1 of the OSI reference model for the radio channel supervises between the mobile station MS and the 
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respective base stations BS. 

iii) Layer 2 of the OSI reference model for the radio channel supervises between the mobile station MS and the 
base station controller RNC. 

iv) Layer 3 of the OSI reference model for the system supervises between the mobile station MS and the base sta- 
5 tion controller RNC or between the mobile station MS and the mobile service switching center MSC. 

[0172] In addition, Layer 2 should meet the following functional conditions: 

i) At the source, it has a function to retransmit layer-2 frames 
10 ii) At the destination, it has a function to reassemble !ayer-3-frames from received layer-2-frames in the regular 
order even if a layer-3-frame was divided into a plurality of layer-2-f rames at the source, 
iii) At the destination, it does not have a function to interpret a ciphered signal and non-ciphered signal both corre- 
sponding to the same information when it receives them simultaneously. 

is [0173] Under the above-mentioned conditions, assume that layer 2 conducts the encipherment procedure on layer 2. 
In this case, as shown in Figure 754, an application in the mobile service switching center MSC sends an encipherment 
onset indication at step S1 . The encipherment onset indication is transferred from layer 3 to a layer-2-controller at step 
S2, to a layer-2-cipherer/decipherer at step S3, and to the mobile station MS at step S4. 

[0174] The network application then sends an encipherment onset request to the layer-2-cipherer/decipherer of the 
20 mobile station MS via the layer-2-cipherer/dedpherer of the network at step S5. Afterward, the application of the mobile 
service switching center MSC makes the layer-2-cipherer/decipherer of the base station controller RNC carry out the 
encipherment process, whereby the signal transmitted from the layer-2 -cipherer/decipherer are enciphered. 
[0175] In the mobile station MS, the encipherment onset indication is transferred from layer-2-cipherer/decipherer to 
layer-2-controller at step S6, to layer 3 at step S7, and finally to the application at step S8. Upon the reception of the 
25 encipherment onset indication, the application of the mobile station instructs or sets the layer-2-cipherer/decipherer to 
decipher the transmitted signal from the network at step S9. 

[0176] If the second layer conducts the encipherment process under the above-described conditions, the encipher- 
ment is started at the network before the signals are distributed to the radio base stations BS for diversity handover in 
the network. Therefore, the mobile stations can receives the ciphered signals from the respective base stations, thereby 
30 achieving diversity handover surely even if it cannot process in parallel an enciphered signal and non-enciphered sig- 
nal. 

[0177] However, in this case, it is possible that the application of the mobile station requests the layer-2-cipherer/deci- 
pherer to decipher signals (Step S9) simultaneously with the retransmission request from the layer-2-controller in the 
mobile station to the network (Steps S10 to S12). If the network begins to retransmit the requested signals (Steps S13 

35 and S1 4) before the completion of the decipherment set-up in the layer-2-cipherer/decipherer, the layer-2-cipherer/deci- 
pherer will not decipher the enciphered signal and transfer it as it is to the layer-2-controller. In this case, the layers- 
frame sequence number of the signals may not be interpreted. This phenomenon is caused from that although layer 2 
(datalink layer) detects errors occurring at layer 1 (physical layer) referring to CRCs attached to the signal frames and 
facilitates the retransmission, layer 2 also provides the encipherment procedures. 

40 [0178] This results in problems: the first problem is that the retransmitted layer-2 frames cannot be utilized, and the 
second problem is that it is impossible to reassemble layer-3-frames from received layer-2-frames in the regular order 
if a layer-3-frame was divided into a plurality of layer-2-frames at the source. 

[0179] Accordingly, it is preferable that the mutual notification of the encipherment onset (transmission of START 
CIPHERING request indication and START CIPHERING response confirmation) is conducted at the layer which is layer 
45 3 or higher rather than layer 2 in the OSI reference model. Therefore, in the system, ciphered is only information that 
should be processed only in one or more layers which are the same as or higher than layer 3 of the OSI reference model 
although the mutual notification of the encipherment onset time is conducted at layer 2. 

[0180] Consequently, although normal reception is not achieved by an error occurring in layer 1 (physical layer), the 
retransmission can be made out by the error detection and retransmission in layer 2 independently of layer 1 . The 
so retransmission causes the reception of the non-received signals in the proper order by the destination. Therefore, the 
destination can recognize the encipherment onset time at an improved precision. However, if the reliability of layers 1 
and 2 can be improved, it is possible to cipher at layer 2. 

2.2.4 REASSIGNMENT OF TMUI 

55 

[0181] in the system, an IMUI (international mobile user identity) is already assigned to each of the mobile stations. 
Each mobile station stores the corresponding IMUI while the network stores a plurality of IMUI of the mobile stations. 
Communication may be carried out using the IMUIs, but they can be intercepted by a third party since mobile commu- 
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nications may be achieved by the air interface. This results in that the third party can communicate using the intercepted 
IMUI. 

[0182] Therefore, in the present system, the network assigns another identity, namely, TMUI (temporary mobile user 
identity) to each of the mobile stations that is communicable with the network and notifies the corresponding mobile sta- 
5 tion about TMUI. More specifically, the TMUI is enciphered to be preserved from being intercepted, and then transmit- 
ted through the air interface to the mobile station. 

[0183J The assignment of TMUI is conducted at the location registration procedure. If the location registration proce- 
dure is failed, the location registration procedure should be repeated again. Therefore, confusion of TMUI at each 
mobile station will not occur in theory. However, if a machine storing TMUI in a mobile station or the network malfunc- 
w tions, such confusion of TMUI and IMUI may occur. 

[0184] In this case, recovery process is needed for correcting the confusion. Therefore, the system adopts the follow- 
ing procedures, which should be carried out by the network and the mobile station MS. 

[0185] Figure 264 represents a sequential operation by the network and a mobile station MS. This operation starts 
after a call attempt comes into the network from a user terminal other than the mobile station MS illustrated in Figure 
is 264. Once the network (more exactly, the mobile communications control center) receives a call income, the mobile 
communications control center first carries out a paging in a manner that TMUI of the incoming call destination is spec- 
ified, as shown in Figure 264. This paging process is a broadcasting of TMUI to the areas of which the mobile commu- 
nications control center MCC is in charge. 

[01 86] As mentioned above, TMUI is assigned to each mobile station MS communicable with the mobile communica- 
te tions control center MCC and each mobile station MS stores its TMUI. Therefore, once mobile stations MS receive the 
broadcast TMUI, each mobile station determines whether the broadcast TMUI is coincident with the TMUI stored 
therein. If the determination is affirmative, only the corresponding mobile station MS sends a paging response to the 
mobile communications control center MCC at step S2. 

[0187] Next, the network checks the authenticity of the user (see section 2.3.2.4.1). More specifically, the network 

25 generates a necessary authentication information (random number) for checking the authenticity of the accessing 
mobile station MS and transmits it to the mobile station MS at step S3. Once the mobile station MS receives the authen- 
tication information, the mobile station MS executes an arithmetic operation based on the authentication information 
(random number) and transmits the authentication calculation result as an authentication response at step S4. The 
authentication calculation uses an authentication key stored in each mobile station MS previously. The network stores 

30 the authentication keys of the respective users at its storage device (e.g., SDF) in a manner that the respective authen- 
tication keys are associated with the respective IMUIs and TMUIs for finding the correlation. 
[0188] Then, the network reads out the authentication key corresponding to the temporary mobile user identity used 
for the paging at step S1 . Next, the network executes the authentication calculation on the basis of the read authenti- 
cation key and the authentication information (random number) transmitted at step S3, and determines whether or not 

35 this calculation result is coincident with the calculation result by the mobile station MS at step S5. If the determination 
is affirmative (the results are coincident), the mobile station MS is authenticated (the mobile station belongs to a proper 
subscriber and is the proper call destination). Afterward, a normal incoming call acceptance procedure is executed. 
[0189] However, if the determination is negative (the results are not coincident), the mobile station MS is not the call 
destination. Such a discord is caused from that the replying mobile station MS is fraudfull or TMUI managed by the net- 

40 work and TMUI managed by the proper subscriber's mobile station became discord with each other accidentally. 
Accordingly, the network checks the authenticity of the mobile station using the international mobile user identity. 
[0190] Specifically, first the network (in fact, the mobile communications control center) transmits an IMUI transmis- 
sion request to the mobile station MS for instructing it to transmit the IMUI at step S6. In response, the mobile station 
MS notifies the IMUI stored in itself. 

45 [0191] The network then generates the random number again as the authentication information and sends it to the 
mobile station MS. In response, the mobile station MS uses the authentication information and the authentication key 
stored in itself to execute an authentication calculation and sends the authentication calculation result as an authenti- 
cation response to the network at step S9. 

[01 92] The network then accesses to the storage device thereof and reads out the authentication key corresponding 
so to the IMUI obtained at step S7. Next, the network executes the authentication calculation on the basis of the read 
authentication key and the authentication information (random number) transmitted at step S8, and determines if this 
calculation result is coincident with the calculation result by the mobile station MS or not at step S10. If the determina- 
tion at step S10 is negative (the results are not coincident), the mobile station MS is completely fraudfull, so that the 
radio channel between the network and the mobile station MS is disengaged, thereby finishing the communication at 
55 step S12. 

[0193] On the contrary if the determination at step S10 is affirmative (the results are coincident), the mobile station 
MS can be considered to belong to a proper subscriber, but its TMUI was altered accidentally. Thus, the mobile com- 
munications control center MCC reassigns TMUI at step S11 . In other words, as long as the mobile station MS belongs 
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' to a proper subscriber, it can obtain TMUI again and afterward it can communicates with the network by means of the 

, newly assigned TMUI although the former TMUI has been changed to null accidentally. However, since the mobile sta- 

tion is not a call destination in fact (although the mobile station belongs to a proper subscriber), the radio channel 
between the network and the mobile station is disconnected, so that the communication is ended at step S12. 
5 [0194] As described above, according to this reassignment of TMUI, although TMUI stored in the network and TMUI 
stored in the mobile station MS is different, the network can recognize that mobile station MS belongs to a proper sub- 
scriber as long as the IMUI is correct and can reassign the new TMUI to the mobile station MS. Therefore, although the 
former TMUI has been changed to null accidentally, the mobile station can be returned quickly to the normal condition 
in which it can communicate normally. 
w [0195] Furthermore, when the location of the mobile station is registered or the mobile station request the call origi- 
nation as well as the incoming call acceptance described above, the authentication using the TMUI is conducted. In this 
case, the reassignment of the TMUI is conducted if necessary. In the network, the TMUIs are managed by SDF, which 
will be described later. SDF can be, for example, arranged in a location register for managing various information on 
subscribers in the network. 

15 

2.3 BRIEF DESCRIPTION OF SYSTEM 

[0196] Next, the system will be described briefly. 

20 2.3.1 PROVIDED SERVICES 

[0197] This system can totally provide various information transfers including voice transfer and data transfer. This 
system can also provide one mobile station with a plurality of bearer services at the same time. For example, the single 
mobile station can benefit by two unrestricted digital bearer services at 64 kbps simultaneously. Furthermore, unlike the 
25 traditionally PDC mobile communications system, the wire communication meets the requirements of ATM and the 
radio communication meets the requirements of CDMA, whereby transfer is achieved at improved quality and improved 
velocity. 

[0198] Figure 266 shows the features of services, which can be provided by this system. In addition, the present sys- 
tem can be connected with another system managed in accordance with PSTN, N-ISDN, PLML, B-tSDN, or IMT-2000. 

30 

2.3.1.1 BEARER SERVICES 

[0199] This system can provide the following bearer services. 
35 (1) Circuit Switching Mode 

a) Voice Bearer Service at 8 kbps 

[0200] This bearer service is provided for supporting voice services. The digital signals at the Urn reference point 
40 comply with ITU-T recommendation G.729. However, the bit transparency is not ensured. This bearer service will not 
be utilized for voice-band data communication. The features of the voice bearer service at 8 kbps are listed in Figure 
267. 

b) Unrestricted Bearer Service at 64 kbps 

45 

[0201] This bearer service provides information transfer at 64kbps, the information being not changed between the 
Urn reference points. The features of the unrestricted bearer service at 64 kbps are listed in Figure 268. 

c) Multiplex-Rate unrestricted Bearer Service at n x 64 kbps (n is a natural number, e.g., 6) 

50 

[0202] This bearer service provides information transfer at 384 kbps wherein subrate information is multiplexed with 
one another, the subrate information being not changed between the Urn reference points. The features of the multiple- 
rate unrestricted bearer service are listed in Figure 269. 

55 (2) PACKET SWITCHING MODE (should be studied further) 

[0203] This system can provide bearer services at the packet switching mode in addition to those at the circuit switch- 
ing mode. 
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2.3,1.2 MOBILITY SERVICE 

[0204] In order to facilitate the mobility or portability services, international mobile user identity (IMUI) is adopted. IMUI 
is previously assigned to each of the mobile stations for identifying the respective mobile stations. Each mobile station 
5 stores its IMUI while the network mobile communications control center MCC stores a plurality of IMUIs of the mobile 
stations that are served by the network. When one mobile station moves to a next radio zone, the IMUI of the mobile 
station is utilized for the location registration and handover, so as to enable the mobile station to communicate irrespec- 
tively of its location. 

w 2.3.1.3 QUALITY REQUIREMENTS 

[0205] This system enables error correction coding and retransmission functions. Therefore, the average bit-error rate 
in the network and the air interface is ensured to be less than 10* 3 in relation to voice transfer. In relation to transfer of 
information, e.g., data or control information other than voice, the average bit-error rate is ensured to be less than 10* 6 . 

15 

2.3.2 SYSTEM CAPABILITIES 

2.3.2.1 SYSTEM CAPABILITIES ON CONNECTION SERVICES 

20 2.3.2.1.1 ORIGINATION 

[0206] "Origination" is a series of controlling procedures for setting up the intra-network and network-MS access links 
necessary for communicating with a called terminal and for setting up connection to the called terminal on the basis of 
an access of a calling mobile station upon a call attempt by the user of the calling mobile station. "Origination" proce- 
ss dures include an SDCCH control, user identity retrieval, user authentication, encipherment-onset time notification, 
establishment of access link, mutual information transfer to and from the calling user terminal, and analysis. 
[0207] The system comprises the following capabilities for the origination procedures. First, it is possible to establish 
an SDCCH (stand-alone dedicated control channel) to inform the network of the call attempt by the mobile station MS. 
SDCCH will be described later in more detail at the section entitled "SDCCH Control" of this chapter. Furthermore, in 
30 order to establish the association (terminal association) between the mobile station and the network, the system com- 
prises the following functions. 

a) The network is notified of the call attempt indicating the temporary mobile user identity (TMUI) of a calling mobile 
station by the mobile station, thereby setting up the terminal association. In addition, the network is informed of fea- 

35 ture capabilities of the mobile station by the mobile station and the information on the capabilities is stored in the 
network, so that the network controls to allow or reject the another call attempt to the mobile station. 

b) The network recognizes the calling mobile station, which has requested the call attempt, and transfers unique 
information about the calling mobile station from a network data base to analyzing functional entities and control 
functional entities. If the network cannot recognize the temporary mobile user identity (TMUI) the calling mobile sta- 

40 tion, the network sends an inquiry about the international mobile user identity (IMUI) to the calling mobile station 
for recognition. 

c) The user authentication of the mobile station is executed as described above. The user authentication will be 
described in more detail at the section entitled "User Authentication" of this chapter. 

d) In order to preserve signals transmitted through the control channel and the information channel between the 
45 mobile station and the network from being intercepted and manipulated by a third party, signals are ciphered. The 

encipher ment will be described in more detail at the section entitled "Encipherment" of this chapter. 

e) The mobile station is informed of successes and failures of the above-mentioned respective procedures. 

[0208] In addition, the network is informed of the services required by the calling mobile station after the establishment 
so of the terminal association. In addition, the network informs the calling mobile station of the acceptance of the call 
attempt after the establishment of the terminal association. 

[0209] Additionally, a call origination control function is informed of an instance of the terminal association control 
function, whereby they are associating with each other. 

[0210] Trie mobile station informs the network of the environmental radio condition around the mobile station when 
55 the calling mobile station sends the call attempt, whereby the network recognizes the condition. 

[0211] Upon the reception of the call attempt from the mobile station, the user profile of the originating terminal is 

retrieved and analyzed, so that the services that can be provided for the originating terminal are determined. 

[021 2] On the basis of the analysis of on the call attempt from the mobile station, appropriate network resources, for 
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instance, voice coder-decoders, data trunks, and wired channels in the network are captured, set up, and activated. 
[021 3] The access link for the traffic channel and the associated control channel, which are suitable for the services 
requested by the calling mobile station, can be established (refer to the section entitled "Access Link Establishment" in 
this chapter). Once the associated control channel is established, the SDCCH transferring previously the control signals 
5 is released. The release of the SDCCH will be described in more detail at the section entitled "SDCCH Control" in this 
chapter. 

[0214] The called user terminal is requested to communicate with the originating user terminal. While the called ter- 
minal is requested to communicate, the originating user terminal is informed of the calling to the called user terminal 
and the response from the called user terminal. 
10 [021 5] The calling or called mobile terminal, for which the call has been established, can originate another call (addi- 
tional call). However, since the mobile terminal has been already authenticated, the authentication process is not car- 
ried out for the additional call. 

[021 6] In addition, although a call has been established between terminals, another call requested from a third party 
may be established. 

15 

2.3.2.1 .2 INCOMING CALL ACCEPTANCE 

[021 7] "Incoming call acceptance" is a series of controlling procedures wherein the networks calls a destination user 
mobile station upon a service request from a calling user terminal, and receives the response from the destination user 

20 mobile station so that access-links within the network and between the network and the mobile station are established, 
and connection between those mobile stations are established for the communication between the calling and destina- 
tion user terminals. "Incoming call acceptance" procedures include paging, SDCCH control, user identity retrieval, user 
authentication, encipherment-onset time notification, routing in the network, establishment of access link, mutual infor- 
mation transfer to and from the called user terminal, and analysis. 

25 [021 8] The system comprises the following capabilities for the termination procedures. 

[0219] First, the network receives a call attempt from a calling user terminal which may be a subscriber terminal of 
this system or another system connected thereto. Then, the network retrieves the profile of the called user terminal on 
the basis of the mobile user identity of the called user terminal. Therefore, the network can obtain various information 
necessary for analyzing the services which can be provided for the called user terminal, for analyzing the condition of 

30 the called user terminal, for determining if paging is necessary or not, for determining the areas for the paging, and for 
establishing the terminal association between the network and the called user terminal. Then, the paging function entity 
of the network is activated for paging. However, the paging is not carried out for the additional call. 
[0220] The called mobile station is called by means of the mobile user identity of this mobile station. The network can 
recognize the responding mobile station. Usually, in this procedure, TUMI may be used for the mobile user identity. If 

35 the network detects an abnormality of the TMUI, the IMUI uniquely given to the mobile station is used. The paging pro- 
cedure may be realized by the following capabilities. 

a) The network recognizes the area or areas where the called mobile station is paged, and then determines the 
paging channels used for the paging. Then, the network distributes a paging signal to intra- network nodes (base 

40 terminal systems). In response, each BTS transmits a paging signal in its coverage sector for paging the called 
mobile station within the necessary area. 

b) An SDCCH is established in order that the mobile station sends the network a response to the paging. This fea- 
ture will be described in more detail at the section entitled "SDCCH" control in this chapter. 

c) Once the called mobile station sends the network the response to the paging, the terminal association between 
45 the called mobile station and the network is activated. In addition, the response signal can be identified by a paging 

ID corresponding to the calling signal. Furthermore, the mobile station notifies the network about the capability of 
the mobile station. The network stores the information on the mobile station capability for future reception manage- 
ment of another new call attempt to the mobile station. 

so [0221] The mobile station informs the network of the environmental radio condition around the mobile station when 
the mobile station responds to the paging, whereby the network recognizes the condition. 

[0222] Once the mobile station responds to the paging, the network establishes the terminal association between the 
network and the mobile station. The establishment of the terminal association is executed as follows: 

55 a) The user authentication of the mobile station is executed as described above. The user authentication will be 
described in more detail at the section entitled "User Authentication" of this chapter. 

b) In order to preserve signals transmitted through the control channel and the information channel between the 
mobile station and the network from being intercepted and manipulated by a third party, signals are ciphered. The 
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enciphermerrt will be described in more detail at the section entitled "Encipherment" of this chapter. 

c) The mobile station is informed of successes and failures of the above-mentioned respective procedures. 

[0223] After the establishment of the terminal association, a routing process is carried out for specifying the route to 
5 the intra-network control node which has controlled the establishment, and then the intra-network control node is 
informed of the setting up of the channels within the network and the services requested by the originating user termi- 
nal, so as to activated the incoming call acceptance control function. Additionally, the incoming call acceptance control 
function is informed of an instance of the terminal association control function, whereby they are associating with each 
other. 

10 [0224] Upon the call attempt, the user profile of the called terminal is retrieved and analyzed, so that the services that 
can be provided for the called terminal are determined. 

[0225] On the basis of the analysis of on the call attempt, appropriate network resources, for instance, voice coder- 
decoders, data trunks, and wired channels in the network are captured, activated and set up. 
[0226] The access link for the traffic channel and the associated control channel, which are suitable for the call 

is attempt, can be established as will be described at the section entitled "Access Link Establishment" in this chapter. 
Once the associated control channel is established, the SDCCH transferring previously the control signals is released. 
The release of the SDCCH will be described in more detail at the section entitled "SDCCH Control" in this chapter. 
[0227] The called user terminal is informed of a service request from the originating user terminal. While the called 
terminal is informed of the service request, the originating user terminal is informed of the calling to the called user ter- 

20 minal and the response from the called user terminal. 

[0228] Although a call has been established between terminals, another call requested from a third party may be 
established. 

[0229] In addition, the calling or called mobile terminal, for which the call has been established, can respond to 
another call (additional call). However, since the mobile terminal has been already authenticated, the authentication 
25 process is not carried out for the additional call. 

[0230] Furthermore, if a plurality of mobile stations respond to the incoming call acceptance paging, a new TMU! is, 
during the termination procedures, reassigned to one of the mobile station where the stored TMUI is changed acciden- 
tally. 

30 2.3.2.1.3 CALL RELEASE 

[0231] "Call release" is a series of procedures for releasing the link within the network and the access link between 
the mobile terminal and the network used for a call, and releasing the connection between the mobile terminal and the 
other user terminal. The call release is carried out upon a call release request from the mobile terminal or the other user 

35 terminal, or upon a detection of the deterioration of the radio communication quality. The call release includes a user 
disconnection procedure (updating the user status data) and a procedure for releasing access links. 
[0232] When releasing the last call for a mobile station, the association between the mobile station and the network 
is released. This process accompanies with updating the status data in connection with the mobile station. 
[0233] For executing the call release, the system comprises the following capabilities. 

40 [0234] The network is notified of a call release request from a user terminal, and the user terminal is notified of the 
acceptance of the release request by the network. 

[0235] In addition, the network informs the user terminal of a call release request from the other user terminal. 

[0236] In order to update the user status data when the call release occurs, the user profile is updated. 

[0237] The access link corresponding to the released call is also released as will be described in more detail at sec- 
45 tion 3.2.2.3 entitled "Access Link Release." 

[0238] It is determined as to if the released call is the last call for the mobile station or not. If it is the last call, the status 

data in connection with the mobile station managed in the network is updated to indicate none call status. 

[0239] Call can be also released upon an access link release procedure (refer to section 3.2.2.3 entitled "Access Link 

Release") resulting from the detection of out of synchronization. 
so [0240] Call can be also released upon a call release request from the mobile terminal. 

[0241 ] Call can be also released if the originating mobile station abandons the call. 

2.3.2.2 SYSTEM CAPABILITIES ON ACCESS LINK CONTROL 

55 2.3.2.2.1 SDCCH CONTROL 

[0242] "SDCCH Control" includes a procedure for establishing an SDCCH (stand-alone dedicated control channel) 
for transporting control massages between the mobile station and the network and a wired access link for transporting 
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the control messages within the network on the basis of an access of a mobile station; and a procedure for releasing 
the SDCCH and the wired access link within the network when they become not necessary. These procedures are car- 
ried out for every process, which needs the interaction between the mobile station and the network, e.g., the mobile sta- 
tion call origination process, the mobile station call termination process, and the mobile station location registration. 

5 [0243] In order to execute the SDCCH control, the system comprises the following functions. 

[0244] The mobile station executes a random access procedure over the RACH (random access channel) and 
requests the network to establish the SDCCH. In response, the network assigns radio resources (uplink and downlink 
codes) for the SDCCH to the mobile station using a FACH (forward access channel). The relationship between the 
establishment request and the assigned the code resources are determined by a random number (personal identrfica- 

10 tion or PID) contained in the request message transmitted by the mobile station. 

[0245] In addition, the network can select the radio resources (uplink and downlink short codes) for the SDCCH for 
each sector from the resources managing for the sector. Unique uplink and downlink long codes are used for each base 
station. In addition, the phase of long codes used for each sector in a cell is different from that used for the other sectors 
in the same cell. Thus, the mobile station obtains the current downlink long codes by a cell search process or broadcast 

15 information from a broadcasting channel BCCH1 and obtains the current uplink long codes by broadcast information 
from the broadcasting channel BCCH1. 

[0246] The network also establishes a wired access link for transferring the control messages within the network upon 
the establishment request for the SDCCH from the mobile station. 

[0247] It is possible to recognize information on the location of the mobile station when requesting to establish the 
20 wired access link within the network. 

[0248] It is possible to control the power for transmission through the RACH, FACH, and SDCCH. The control manner 
will be described at section 2.3.2.2.6 in more detail. 

[0249] The network and mobile station can recognize that the status in which the SDCCH is unnecessary since, for 
instance, a process, e.g., the location registration which is not associated with call is ended or transited to the ACCH. 
25 Then, the network and mobile can release the SDCCH respectively. 



2.3.2.2.2 ACCESS LINK ESTABLISHMENT 



[0250] "Access link establishment" is a series of procedures for setting up a traffic channel for transferring user infor- 
30 mation and control channels for transferring control information between the network and the mobile station that origi- 
nates a call or is called. These procedures include establishing wired access link in the network and radio access link 
between the network and the mobile station. 

[0251 ] In order to execute the access link establishment the system comprises the following capabilities. 
[0252] The network determines information transfer capabilities and quality levels needed for the respective connec- 
35 tion access links on the basis of a call/connection control request, and then allocates appropriate resources to the 
access links. 

[0253] The mobile station designates candidate sectors, for which the wired access links or radio access links should 
be established, on the basis of the measurements of the perch channels and the broadcast information from the net- 
work. Then, the mobile station informs the network of the candidate sectors. The call acceptance control procedure will 
40 be described in more detail at section 2.3.2.2.7. 

[0254] The network sets up the wired access link between the network and the respective candidate sectors. Each 
established wired access link includes the traffic channel for transferring user information and, if necessary the control 
channel for transferring control signals. 

[0255] The network stores the uplink long codes for radio access links in a database within the network according to 
45 MS identifiers (TMUI/IMUI). The network retrieves the information from the database to set up an access link. 

[0256] The network selects radio resources for the radio access link in the specified sector and allocate them to the 
mobile station. The radio resource selection will be described in more detail at section 2.3.2.2.5. 
[0257] The mobile station transmits information to the network for determining the initial power for transmission 
though the downlink radio access link, the information being based on the measurements on the perch channel and 
so including information on the power for transmitting through the perch channel and the signal-to-interference ratio about 
the signal received from the perch channel. 

[0258] The network determines the initial power for transmission through the downlink radio access link upon the 
reception of the information from the mobile station. The control of the transmission power will be described in more 
detail at section 2.3.2.2.6. 

55 [0259] The base station controller receives information on the wired access links and the radio access links and is 
able to start diversity handover based on the information at the same time when the access links are established for the 
candidate base stations, and carries out diversity handover on the basis of the information on the candidate sectors. 
Handover procedures will be described in more detail at section 2.3.2.2.4. 
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[0260] The mobile station informs the network of the respective phase differences upon a broadcast information (peri- 
odical broadcasts at the intervals of 20 msec), each phase difference being the difference between the uplink long code 
phase of the sector to which the SDCCH is established and the uplink long code phase of another candidate sector 
[0261 ] The network synchronizes the uplink radio access links on the basis of the uplink long code phase difference 
s information from the mobile station. 

2.3.2.2.3 ACCESS LINK RELEASE 

[0262] "Access link release" is a series of procedures for releasing all traffic channels for transferring user information 
w between the network and the mobile station and all control channels for transferring control information therebetween. 
"Access link release" procedures include a procedure for releasing wired access links in the network and radio access 
links between the network and the mobile station. 

[0263] In order to execute the access link release procedures, the system comprises the following capabilities. 
[0264] Due to release of an individual connection or release of connections for a released call, the network releases 
75 the corresponding access link. The release of access link is requested from the network to the corresponding mobile 
station. 

[0265] If the network detects out-of-synchronization status in connection with all handover branches involved in an 
access link and does not detect the synchronization status again for a certain time period counted by a squelch reser- 
vation timer, the network executes to release the access link. 
20 [0266] If the mobile station detects out-of-synchronization status in connection with all handover branches involved in 
an access link, the mobile station stops to transmit over radio channels involved in the access link and causes the net- 
work to recognize that the out-of-synchronization status occurs. It is possible that the mobile station informs the network 
of the occurrence of the out-of-synchronization. 

[0267] When an access link is released during diversity handover, all the handover branches involved in the access 
25 link are also released. 

2.3.2.2.4 HANDOVER 

[0268] "Handover" is a series of procedures for altering the access point through which a mobile station accesses the 
30 network while the communication therebetween is continued. The handover is necessary for the reason of travelling of 
the mobile station and deterioration of the communication quality, or in order to distribute traffic. The handover proce- 
dures include alteration of radio access link and if necessary, alteration of wired access link. In order to execute hando- 
ver, the system comprises the following capabilities. 

[0269] The system can execute various types of processes for realizing handover as described below. 



35 



a) INTER-SECTOR HANDOVER BRANCH ADDITION IN SINGLE CELL 



[0270] Near the boundary between sectors in a single cell, added is a branch for a new sector, which is different from 
the sector currently used, but in the same cell. This addition does not accompany with an addition of the wired access 
40 link in the network. 

b) INTER-CELL HANDOVER BRANCH ADDITION 

[0271] Near the boundary between cells, added is a branch for a new cell, which is different from the cell used cur- 
45 rently. This addition does accompany with an addition of the wired access link for the newly added cell in the network. 

c) INTER-SECTOR HANDOVER BRANCH DELETION IN SINGLE CELL 

[0272] Near the boundary between sectors in a single cell, deleted is one of handover branches for the sectors when 
so intra-cell diversity is no longer necessary. This deletion does not accompany with a deletion of the wired access link in 
the network. 

d) INTRA-CELL HANDOVER BRANCH DELETION 

55 [0273] Near the boundary between cells, deleted is one of handover branches for the cells when inter-cell diversity is 
no longer necessary. This deletion does accompany with a deletion of the wired access link for the newly deleted cell 
in the network. 
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e) INTRA-CELL BRANCH REPLACEMENT HANDOVER 

[0274] At a boundary between sectors in a single cell, all handover branches are released, and then a new access 
link is established for the sector, which should be newly served. rf the service attributes are not necessary to be 
5 changed for this handover, the wired access link in the network is left. 

f) INTER-CELL BRANCH REPLACEMENT HANDOVER 

[0275] At a boundary between cells, all handover branches are released, and then a new access link is established 
10 for the cell, which should be newly served. If the service attributions are not necessary to be changed for this handover, 
the wired access link in the network is left. 

g) INTRA-SECTOR FREQUENCY REPLACEMENT HANDOVER 

is [0276] For all handover branches being used for communication, the radio frequency is replaced by another fre- 
quency. This handover does not accompany with an addition or deletion of the wired access link in the network. 

h) CODE REPLACEMENT HANDOVER 

20 [0277] For a handover branch being used for communication, the downlink short code is replaced by annother down- 
link short code belonging to the same code type in the same sector. This handover does not accompany with a replace- 
ment of the wired access link in the network. 

i) USER DATA RATE MODIFICATION 

25 

[0278] In order to alter user-to-user connection attributions, e.g., the user data rate or voice/data type, all handover 
branches for the connection is released, and then access links for the altered connection are established. 

j) ACCH REPLACEMENT 

30 

[0279] Although radio resources used by an ACCH are released for the reason that a connection or call is released, 
it is sometimes necessary to continue another call. In this case, the ACCH is handed over to the wired access link and 
radio access link that has been used for the remaining call. 

[0280] When control signals are transported through an ACCH corresponding to a connection, it is sometimes nec- 
35 essary to after the transmission rate. In this case, the ACCH is handed over to the wired access link and radio access 
link that has been used for another connection. 

k) CODE TYPE REPLACEMENT 

40 [0281 ] "Code type replacement" may be carried out. In this case, for all handover branches being used for communi- 
cation, the downlink short codes are replaced by downlink short codes belonging to a different code type in the same 
sector. This handover does not accompany with a replacement of the wired access link in the network. 
[0282] By the above-mentioned handover branch addition, the maximum number of handover branches availed for all 
simultaneous connections is "N." 

45 [0283] The mobile station, on the basis of the perch channel measurements and call acceptance information from the 
network, requests the network to activate the handover branch addition, handover branch deletion, and branch replace- 
ment handover. The request information for the activation includes the information for designating the candidate sectors 
for handover. The call acceptance control will be described in more detail at section 2.3.2.2.7. 
[0284] Upon the reception of the activation request, the network selects the sectors for handover from the candidate 

so sectors. 

[0285] In the handover branch addition, the network assigns the radio frequency band, which is the same as of the 
currently used branch, to the channel for the additional branch, the radio frequency band being the radio resource. In 
addition, the network assigns the same uplink code resources to all of the branches for one connection. The selection 
of the radio resources will be described in more detail at section 2.3.2.2.5. 
55 [0286] When it is impossible to carry out the handover because of a deficiency in necessary radio resources or intra- 
network resources, the network ignores the handover request from the mobile station. If the mobile station does not 
. receive the handover executing instruction, from the network for a certain time, that should be transmitted upon the 
reception of the handover request from the same mobile station, the mobile station analyzes the necessity of handover 
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again. Then, the mobile station requests the network to execute the handover again if it is determined to be necessary 
[0287] The mobile station sends the network the information to be used for determining the initial transmission power 
over the downlink access link of the additional branch. The information is based on the perch channel measurements. 
[0288] Upon the reception of the information for determining the initial transmission power, the network determines 
5 initial transmission power over the downlink access link of the additional branch. The transmission power control will be 
described in more detail at section 2.3.2.2.6. 

[0289] In the handover branch addition, based on a broadcast information (periodical report information) at the inter- 
vals of 20 msec, the mobile station informs the network of the phase difference of uplink long codes among the respec- 
tive candidate sectors, and the group of frame offsets and group of slot offsets used in the mobile station. 
10 [0290] Upon the reception of notification of the uplink long code phase difference information and the groups of frame 
offsets and slot offsets, the network establishes the synchronization of the uplink radio access link of the sector corre- 
sponding to the added branch. 

[0291] At the same time for execution of the branch addition, intra-sector frequency replacement handover, or user 
data rate modification, it is possible to execute the handover branch addition at boundary between sectors in single cell 
15 or at the boundary between cells. By the handover branch addition at boundary between sectors in single cell or at the 
boundary between cells, the maximum number of newly added handover branches is N - 1 . 
[0292] The handover branch addition and handover branch deletion can be executed at the same time. After the exe- 
cution of the handover branch addition and handover branch deletion in the combined manner, the maximum number 
of the branches is"N." 

20 [0293] At the same time for execution of the access link establishment, the handover branch addition, branch replace- 
ment handover for another connection, ACCH replacement or the code type replacement maybe executed for another 
connection. 

[0294] The network requests the mobile station to replace the short codes in order to utilize the short code resources 
efficiently. 

25 [0295] At the same time for the releasing access links, the ACCH replacement is also carried out. 
[0296] However, handover of the SDCCH is not carried out. 

2.3.2.2.5 RADIO RESOURCE SELECTION 

30 [0297] "Radio resource selection" is a selection of suitable radio resources, for instance, radio frequency channel, 
short codes, offsets, on the basis of information transmitted from the mobile station to executing the SDCCH establish- 
ment, access link establishment, and the procedures for handover. For the radio resource selection, the system com- 
prises the following capabilities. 

[0298] The mobile station informs the network of the radio capabilities, for example, the available radio frequency 

35 channels or available spreading codes of the mobile station. 

[0299] The network retrieves uplink long codes from a database in the network, the uplink long codes being associ- 
ated with respective mobile stations, so that each mobile station corresponds to unique uplink long codes. 
[0300] The network manages the states of respective uplink short codes (if the uplink short codes are used by mobile 
stations or not) for each sector and selects the uplink short codes for respective connections. The network also deter- 

40 mines to execute or refuse the requested radio resource selection on the basis of the respective uplink interference lev- 
els of the sectors, requested transmission rate, and requested quality level. 

[0301] The network manages the states of respective downlink short codes (the downlink short codes are used by 
the respective mobile station or not) and selects the downlink short codes for respective connections in accordance with 
a request. 

45 [0302] The network selects the group of radio frame offsets and group of slot offsets during the radio resource selec- 
tion for the SDCCH establishment and access link establishment. 

2.3.2.2.6 TRANSMISSION POWER CONTROL 

so [0303] "Transmission power control" includes an initial transmission power determination process for determining the 
initial transmission power for transmitting signals through the radio access link at the start of signal transmission 
through the RACH (random access channel) or the FACH (forward access channel), at the SDCCH (stand alone dedi- 
cated control channel) establishment at access link establishment, or at procedures for handover; and a downlink trans- 
mission power control for respective handover branches during diversity handover. However, the transmission power 

55 control does not include the transmission power control executed at layer 1 . 
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(1) INITIAL UPLINK TRANSMISSION POWER DETERMINATION 

[0304] Power for transmission over the uplink radio channel from the mobile station to the base station should be min- 
imized as smalt as possible to reduce the capacity of the uplink radio channel and to prevent other radio access links 
5 from affected. For this purpose, it is preferable to select the radio zone in which the power can be minimized for signal 
conveyance when selecting the radio zone whose base station should be ready (on standby) for communication with 
the mobile station immediately or will commence communication with the mobile station after handover. Therefore, 
means for the selection is necessary. 

[0305] However, traditional mobile stations simply detect respective reception levels or respective SIRs (signal-to- 
10 interference ratios) of channels for the base stations as information used for radio zone selection. Furthermore, the 
respective transmission power levels vary according to the base stations sometimes. Therefore, in traditional commu- 
nications systems, it is impossible for each mobile station to optimize the uplink transmission power from the mobile sta- 
tion itself to the network 

[0306] In order to resolve these issues and determine the initial uplink transmission power optimally, the system com- 

15 prises the following capabilities. 

[0307] Using the periodical report (information broadcast at the intervals of 20 msec) via perch channels, the network 
broadcasts calibrated perch channel transmission power levels. The calibrated perch channel transmission power lev- 
els has been calibrated in view of the respective path losses at cables and so on within the respective base stations. 
[0308] Using the periodical report (information broadcast at the intervals of 20 msec) via perch channels, the network 

20 also broadcasts uplink interference levels. 

[0309] On the basis of the calibrated perch channel transmission power levels, the respective uplink interference lev- 
els, the respective perch channel reception power levels measured at the mobile station, and respective signal-to-inter- 
ference ratios involved in reception at the respective near base stations, the mobile station can determine the initial 
uplink transmission power level. The signal-to-interference ratios as reference data are previously stored in the mobile 

25 station. 

[0310] With reference to Figure 792, the initial uplink transmission power determination will be described below. 
[031 1 ] In Figure 792, two base stations "A" and "B" transmits the broadcast information via the corresponding perch 
channels. The calibrated perch channel transmission power levels are Pa and Pb, respectively. The respective recep- 
tion levels of the broadcast information at the mobile station via the perch channels from the base stations are Ra and 
30 Rb. The mobile station can calculate the respective path losses on the basis of the perch channel transmission power 
levels Pa and Pb indicated in the broadcast information and the respective perch channel reception levels Ra and Rb. 
More specifically, the path loss Lpa from the base station ff A" to the mobile station is calculated by the next formula. 

Lpa = Pa - Ra 

35 

[031 2] The path loss Lpb maybe calculated similarly. 

[031 3] On the basis of the calculated respective path losses in relation to the base stations, the respective uplink inter- 
ference levels in relation to the base stations, and respective signal-to-interference ratios involved in reception at the 
respective near base stations, the mobile station calculates respective necessary uplink transmission power levels 

40 between the mobile station and respective near base stations. This calculation is conducted for selecting the radio zone 
to which a mobile station should camp on or should be handed over. More specifically, the mobile station selects the 
radio zone in which the necessary uplink transmission power level is minimum among the respective necessary uplink 
transmission power levels, and optimizes (minimizes) the uplink transmission power in accordance with the selected 
radio zone (selected base station). Accordingly, although the respective transmission power levels of the perch chan- 

45 nels vary according to the base stations, each mobile station can optimize the uplink transmission power in the invented 
system. 

(2) INITIAL DOWNLINK TRANSMISSION POWER DETERMINATION 

so 1) FACH AND DOWNLINK SDCCH 

[0314] The mobile station sends information via RACH to inform the network (more exactly, BTS) of the signal-to-inter- 
ference ratio in relation to the perch channel reception at the mobile station. The BTS determines the initial downlink 
transmission power through the FACH (forward access channel) or SDCCH (stand alone dedicated control channel) on 
55 the basis of the perch channel signal-to-interference ratio in relation to the reception at the mobile station, the perch 
channel transmission power level, the required signal-to-interference ratio involved in reception at the mobile station via 
the FACH or SDCCH, and a rate-calibration parameter. The perch channel transmission power level is stored as a ref- 
erence data for the BTS. 
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^ 2) DOWNLINK TCH 



[0315] Using a broadcast channel (BCCH1) mapped at the perch channel, the network (more exactly, BTS) broad- 
casts a perch channel transmission power levels, which is not calibrated. Using the SDCCH, the mobile station informs 
5 the network (more specifically, the base station controller function) of the perch channel reception SIR at the mobile sta- 
tion. Using the SDCCH, the mobile station informs the network (the base station controller function) of the perch chan- 
nel transmission power level which is not calibrated. 

[0316] On the basis of the perch channel signal-to-interference ratio in relation to the reception at the mobile station, 
the non-calibrated perch channel transmission power level, the required signal-to-interference ratio involved in recep- 

10 tion at the mobile station via the TCH (traffic channel), and a rate-calibration parameter, the BSC function in the network 
calculates the initial downlink transmission power through the TCH. The required SIR involved in reception at the mobile 
station via the TCH is stored as a reference data for the BSC function. If there are a plurality of candidate zones from 
which selected is the zone to which the traffic channel is established, the BSC function calculates the respective initial 
downlink transmission power levels of the respective zones and selects the minimal power level. The branch for the 

15 zone corresponding to the minimal power level is the main branch. 

[0317] The BSC function of the network informs the base station of the initial downlink transmission power level. 
[0318] The mobile station can execute the low-rate downlink transmission power control according to layer 3 since it 
is possible that high-rate transmission power control is not executed ordinarily due to the deterioration of transportation 
via a radio branch during diversity handover. 

20 [031 9] The mobile station informs the BSC function in the network of the non-calibrated perch channel transmission 
power level and the perch channel reception SIR periodically. 

[0320] The mobile station increases or decreases the SIR involved in the reception at mobile station, so that the 
reception quality at the mobile station maintains a standard quality. 

[0321] On the basis of the updated values, the network calculates and/or determines the transmission power level 
25 again. 

2.3.2.2.7 CALL ACCEPTANCE CONTROL 

[0322] "Call acceptance control" is a series of control procedures wherein the uplink interference level, downlink trans- 
30 mission power, and activated equipment resources, which can be measured or detected by the base station, are com- 
pared with respective allowable limits; a leeway/restriction (idle/busy) information is produced on the basis of the 
comparison; and a call attempt is allowed or restricted on the basis of the leeway/restriction information at a call origi- 
nation, incoming call acceptance, bearer alteration, or handover. The call acceptance control can be conducted at the 
network and the mobile station. 
35 [0323] However, the call acceptance control at the mobile station is an option. If the call acceptance control is con- 
ducted at the mobile station, it is possible to reduce the number of wastable call attempts, establishment attempts of 
traffic channels, bearer alteration requests, and handover requests. Therefore, the load involved in control procedures 
in the network can be lessened. 

[0324] On the other hand, the call acceptance control at the network is inevitable since the network should recognize 
40 the number of call acceptances and the congestion status of traffic. 

(1) CALL ACCEPTANCE CONTROL AT MOBILE STATION 

[0325] In order that the mobile station carries out the call acceptance control, the system comprises the following 
45 capabilities. 

[0326] Using broadcasting channels (BCCH2), the network broadcasts a call acceptance information. 
[0327] The mobile station refers to the broadcast information, via broadcasting channels BCCH2 from candidate base 
stations from which selected is the base station to which the traffic channel should be established, directly before the 
commencement of the random access for the first call origination, transmission of the setup message for the second 
so call origination, reception of the setup message for call termination, handover trigger transmission, and transmission of 
the setup message to alter the bearer. 

[0328] On the basis of the call acceptance information, the mobile station determines to allow or reject the call 
attempt. 

55 (2) CALL ACCEPTANCE CONTROL AT NETWORK 

[0329] Upon the reception of a request for activatingTCH, the network determines to allow or reject the call attempt 
on the basis of the call acceptance information. 
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2.3.2.2.8 STANDBY CONTROL 

[0330] "Standby control" is controlling to transit the state, so that the mobile station can transmit and receive after the 
power of mobile station is turned on or after the mobile station visits from outside to inside of the network. Additionally, 
5 a procedure for changing the radio zone to camp on due to the travel of the mobile station is called "standby zone tran- 
sition control." 

(1) STANDBY CONTROL 

10 [0331 ] tn order to execute the standby control, the system comprises the following capabilities. 

[0332] Using the periodical report (information broadcast at the intervals of 20 msec) via perch channels, the network 
broadcasts the calibrated perch channel transmission power levels. The calibrated perch channel transmission power 
levels are calibrated in view of the respective path losses at cables and so on within the respective base stations. 
[0333] Referring to the calibrated perch channel transmission power levels in relation to the zones in which the down- 

15 link long codes may be used and the perch channel reception power levels at the mobile station, the mobile station 
selects the zone having the minimum path loss. Then, the mobile station refers to the broadcast information via BOCH1 
corresponding to the selected zone. 

[0334] Using a broadcast channel (BCCH1 ) mapped at the perch channel, the network broadcasts a standby permis- 
sion level, standby deterioration level, network number, restricted information, and so on. 
20 [0335] Referring to the broadcast information via BCCH1 , the mobile station determines to allow or reject the standby. 
[0336] The network, using the broadcast information via BCCH1 at the perch channel, broadcasts the information on 
the data format in the control channel. 

[0337] Referring to the broadcast information via BCCH1 , the mobile station determines the paging channel to which 
the mobile station is connected. 
25 [0338] Referring to the broadcast information via BCCH1 , the mobile station determines the RACH, which the mobile 
station should use. 

[0339] The network, using the broadcast information via BCCH1 at the perch channel, broadcasts the information on 
the uplink long codes for the corresponding zone. 

[0340] Referring to the broadcast information via BCCH1 , the mobile station determines the uplink long codes used 
30 for the RACH and SDCCH. 

(2) STANDBY ZONE TRANSITION CONTROL 

[0341 ] In order to execute the standby zone transition control, the system comprises the following capabilities. 
35 [0342] The network, using the broadcast information via BCCH1 at the perch channel, broadcasts information on the 
downlink long codes for the circumferential zones. 

[0343] The mobile station retrieves the information on the downlink long codes for the circumferential zones from the 
broadcast information via BCCH1 , and conducts the zone transition. 

40 2.3.2.3 SYSTEM CAPABILITIES ON MOBILITY MANAGEMENT 

[0344] Next, system capabilities on mobility management will be described. 

2.3.2.3.1 TERMINAL LOCATION REGISTRATION AND UPDATE 

45 

[0345] For permitting the travel of the mobile terminals, the terminal locations are supervised by the network. There- 
fore, the terminal location data is registered when a user terminal is first detected by the network (when the power of 
the mobile terminal is turned on or the user terminal roams to the network from another network). The terminal location 
data is automatically updated when the location of a mobile terminal changes in the same network 
so [0346] In order to execute the terminal location registration and update, the system comprises the following capabili- 
ties. 

[0347] The network informs a mobile station of the location information, so that the mobile stations recognize the loca- 
tion information. 

[0348] When the mobile station travels in the network, the network recognizes that the mobile station moves from the 
55 location that is managed by the network and requests to update the location information managed in the mobile station. 
[0349] An SDCCH (stand alone dedicated control channel) is established for transporting the control signals for the 
location registration between the network and the mobile station (refer to the section entitled "SDCCH Control"). 
[0350] Terminal authentication is carried out to prevent the network from an access by an improper mobile terminal. 



51 



EP 0 978 958 A1 



Insofar as a terminal is authenticated, the location information on the terminal is updated in the network. 

[0351] The network can assign a new TMUI (temporary mobile user identity) to a mobile station. 

[0352] The network starts the authentication with the IMUI of a mobile station if the mobile station is not authenticated 

by the TMUI check. 

5 [0353] The network notifies the mobile station of the location registration completion. 

[0354] If the mobile station does not receive the location registration/update completion report, the mobile station trig- 
gers the location registration/update procedure again. 

2.3.2.4 SYSTEM CAPABILITIES ON SECURITY SERVICES 

10 

[0355] Next, system capabilities on security services will be described. 

2.3.2.4. 1 USER AUTHENTICATION 

15 [0356] "User authentication- is to determine if each mobile user terminal sending a call attempt to the network is 
proper or not. The user authentication is carried out when a mobile station originates a first call, when a first call is 
directed to a mobile station, or when the location is registered. 

[0357] In order to execute the user authentication, the system comprises the following capabilities. 
[0358] When a mobile station accesses the network, the network produces various information (an authentication cal- 
20 culation result and random number) being necessary for the authentication of the mobile station, and requests the 
mobile station to execute an authentication calculation. The network produces an encipherment key used in an enci- 
pherment calculation after the authentication. 

[0359] The mobile station produces an authentication calculation result based on the random number sent by the net- 
work and informs the network of the result. 
25 [0360] The authentication calculation results made by the network and the mobile station are compared with each 
other. 

[0361] The network sends an inquiry about the international mobile user identity (IMUI) to the mobile station if the 
mobile station has not been authenticated at the authentication procedure using the temporary mobile user identity 
(TMUI). The network then produces the authentication information and executes the authentication procedure using the 
30 IMUI. 

[0362] If the mobile station is not authenticated even at the authentication procedure using the information based on 
the IMUI, the origination procedure, the termination procedure, or location registration procedure is stopped. 

2.3.2.4.2 ENCIPHERMENT 

35 

[0363] "Encipherment" is a series of procedures to cipher control signals or user signals transported through the 
SDCCH, ACCH, or TCH for preventing the signals from being intercepted or edited by a third party. The encipherment 
is carried out at the origination procedure, the termination procedure, or location registration procedure. 
[0364] In order to execute the encipherment, various information, e.g., encipherment keys and relevant information 
40 for producing the encipherment keys, for ciphering or deciphering control signals or user signals that should be trans- 
ported via wireless interfaces are managed. The information is delivered within the network and to the destination 
mobile station when the encipherment is conducted. 

[0365] The delivered information is used for ciphering the signals and the ciphered signals are transported via radio 
interfaces. 

45 [0366] The onset time of ciphering and onset time of deciphering are mutually notified between the network and the 
mobile station. 

2.3.2.4.3 TMUI MANAGEMENT 

so [0367] TMUI is a temporary terminal identifier or user identifier transported via the air interface in order to keep the 
IMUL a secret and to decrease the total length of the terminal identifier. The network assigns the TMUIs to the mobile 
stations communicable with the network and informs the respective mobile stations of the individual TMUIs. After the 
TMUI assignment, the network manages each TMUI all the while the corresponding mobile station exists in the cover- 
age area of the network. The TMUI assignment may be executed at the location registration procedure, origination pro- 

55 cedure. and termination procedure. However, in the invented system, the assignments of TMUIs at origination 
procedure and termination procedure are option. 

[0368] In order to execute the TMUI management, the system comprises the following capabilities. 

[0369] When the network accesses a mobile station for the location registration, location update, origination (option), 
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or termination (option), the network prepares a TMUI for the mobile station and stores it. 

[0370] The network informs the mobile station of the TMUI and confirms that the mobile station stores the TMUI. 
When the location is registered, the mobile station is informed of information indicating the TMUI and the node where 
the TMUI is assigned. However, at the origination or termination, the mobile station is informed of only the TMUI. 
5 [0371 ] The TMUI is seat from the network to the mobile station via the air interface after ciphering for preventing the 
TMUI being intercepted improperly at the air interface. 

[0372] In order to prevent double assignment of the TMUIs, the association of TMUIs and the mobile stations are man- 
aged. 

10 2.3.2.5 SYSTEM CAPABILITIES ON SYSTEM MANAGEMENT 

[0373] Next, system capabilities on system management will be described. 
2.3.2.5.1 REQUIREMENT FOR SYSTEM SYNCHRONIZATION 

75 

[0374] "Requirement for system synchronization" is a requirement for synchronization in the system including the net- 
work and a mobile station in order to perform diversity handover with a minimum buffering delay. In this system, the 
MSC (MCC) and the serving BTSs operate according to the standard clock signal at the regular intervals of 640 msec, 
so that the time alignment is established among the MSC (MCC) and the serving BTSs. However, the phase difference 
20 among the MSC function and the serving BTSs is allowable insofar as it is equal to or less than 5 msec. In other words, 
the requirement for system synchronization is the phase difference within 5 msec. 

2.4 CONTROL MANNERS 

25 [0375] Next, control manners will be described. 

2.4. 1 FUNCTIONAL NETWORK ARCHITECTURE 

[0376] Figure 3 shows the functional network architecture of the system. The functions of the functional entities com- 

30 ply with ITU-T Recommendations. 

[0377] In Figure 3, CCAF (call control agent function) in a mobile terminal is an interface between the user mobile 
terminal and CCF (call control function) of the network for providing access for users. TACAF (terminal access control 
agent function) in a mobile terminal controls access for the mobile terminal, e.g., terminal paging detection. 
[0378] BCAF (bearer control agent function) in the mobile terminal controls radio bearers for the mobile terminal. BCF 

35 (bearer control function) controls bearers. BCFr (bearer control function (radio bearer associated)) in the network con- 
trols radio bearers. 

[0379] TACF (terminal access control function) in the network controls access for the mobile terminal, e.g., terminal 
paging execution. CCF (call control function) controls call and connection. SCF (service control function) controls serv- 
ices. SDF (service data function) stores various data for execution of services. 
40 [0380] LRCF (location registration control function) controls the mobility management. LRDF (location registration 
data function) stores various data for mobility management. SSF (service switching function) is an interface between 
the CCF and SCF and detects the trigger for a service control. SRF (specialized resource function) controls access to 
a special device, e.g., information storing device. 

[0381 ] MCF (mobile control function) in the mobile terminal is an interface to the network for a non-call service. SACF 
45 (service access control function) in the network is an interface to the mobile station for a non-call service. MRRC in the 
mobile station controls radio resources. RRC in the network controls radio resources. 

[0382] MRTR (mobile radio transmission and reception) in the mobile station controls the encipherment or transmis- 
sion and so on. RFTR (radio frequency transmission and reception) in the network controls the encipherment or trans- 
mission and so on. UIMF (user identification management function) stores the information on the mobile users and 
so provides the user authentication and encipherment In the following description, the UIMF may be sometimes called 
UTMF 

[0383] Figure 4 is a diagram showing the functional network architecture of the system, in which functional entities 
are arranged in a communication control plane and a radio resource control plane. In Figure 4, functional entity num- 
bers (FE numbers) are attached to respective functional entities. The correlation between the FE numbers and the func- 
55 tional entities are also represented in Figure 270. 

[0384] In addition, relationships between functional entities are shown in Figure 4. The designations of the relation- 
ships are also stated in the following. 

[0385] The relationship between FE01 and FE06 (CCAP-CCP) is called Relationship ra. 
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The relationship between FE02 and FE05 (TACAF-TACF) is called Relationship rb. 

The relationship between FE07 and FE09 (LRCF-SSF) is called Relationship rc. 

The relationship between FE07 and FE08 (LRCF-LRDF) is called Relationship rd. 

The relationship between FE09 and FE10 (SSF-SRF) is called Relationship re. 

The relationship between FE07 and FE10 (LRCF-SRF) is called Relationship rf. 

The relationship between FE05 and FE07 (TACF-LRCF) is called Relationship rg. 

The relationship between FE05 and FE12 (TACF-SACF) is called Relationship rh. 

The relationship between FE05 and FE06 (TACF-CCF') is called Relationship ri. 

The relationship between FE05 and FE04 (TACF-BCF) is called Relationship rj. 

The relationship between FE05 and FE04a is called relationship rja. 

The relationship between FE05 and FE04b is called relationship rjb. 

The relationship between FE07 and FE12 (LRCF-SACF) is called relationship rk. 

The relationship between FE1 1 and FE12 (MCF-SACF) is called relationship ri. 

The relationship between FE01 and FE02 (CCAF'-TACAF) is called relationship rm. 

The relationship between FE02 and FE03 (TACAF-BCAF) is called relationship rn. 

The relationship between FE13 and FE14 (MRRC-MRTR) is called relationship ro. 

The relationship between FE13 and FE15 (MRRC-RRC) is called relationship rp. 

The relationship between FE15 and FE16 (RRC-RFTR) is called relationship rq. 

The relationship between FE03 and FE04 (BCAF-BCF) is called relationship rr. 

The relationship between FE04 and FE06 (BCF-CCF) is called relationship rs. 

The relationship between FE05 and FE15 (TACF-RRC) is called relationship rt. 

The relationship between FE02 and FE13 (TACAF-MRRC) is called relationship ru. 

The relationship between FE02 and FE17 (TACAF-TIMF) is called relationship rv. 

The relationship between FE1 1 and FE17 (MCF-TIMF) is called relationship rw 

The relationship between FE01 and FE18 (CCAP-UIMF) is called relationship rx. 

The relationship between FE1 1 and FE18 (MCF-UIMF) is called relationship ry. 

The relationship between FE04a and FE04b (BCFr-BCF) is called relationship r44. 

The relationship between FE06 and FE06 (CCF'-CCF') is called relationship r66. 

The relationship between FE07 and FE07 (LRCF-LRCF) is called relationship r77. 

The relationship between FF05 and FF05 (TACF-TACF) is called relationship r55. 

The relationship between FE08 and FE08 (LRDF-LRDF) is called relationship r88. 

The above-described relationships between the functional entities are also represented in Figure 271 . 
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2.4.2 INFORMATION FLOWS OF USUAL COMMUNICATION SERVICES 

2.4.2.1 ORIGINATION FOR INITIAL CALL AND ADDITIONAL CALL 



a) 



FUNCTIONAL MODEL 



40 a-1) 



INITIAL OUTGOING CALL 



[0418] Figure 5 shows the functional model of a part of the invented system for describing the origination for initial 
call. Radio bearers are selected under the BCFr controlled by the same TACF that received a call setup request. 
According to the radio resource selection scenario, multiple FEs are selected. 



a-2) 



ADDITIONAL OUTGOING CALL 
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[041 9] Figure 6 shows the functional model of a part of the invented system for describing the origination for additional 
call. Radio bearers are selected under the BCFr controlled by the same TACF that received a call setup request. 
According to the radio resource selection scenario, multiple FEs are selected. 



b) 



INFORMATION FLOWS 
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b-1) INITIAL OUTGOING CALL 

[0420] Figures 7 and 8 form an information flow diagram showing the origination for initial call. 
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b-2) ADDITIONAL OUTGOING CALL 

[0421] Figure 9 is an information flow diagram showing the origination for additional call. 

5 c) DEFINITIONS OF INFORMATION FLOWS, INFORMATION ELEMENTS, AND FUNCTIONAL ENTITY 

ACTIONS 

[0422] The information flow diagrams will be described supplementally in the following and information elements in 
the flow diagrams will be discussed and represented in tables. 
w [0423] A TA SETUP request indication is used by CCAF in the case of a mobile terminal call origination to request to 
set up a mobile terminal access to the network and the connection between the CCAF and TACAF. Figure 272 repre- 
sents the detail of the TA SETUP request indication. 

[0424] Another TA SETUP request indication is sent from TACAF to request the establishment of the terminal access, 
i.e., signaling connection between TACAF and TACF. Figure 273 represents the detail of the TA SETUP request indica- 
15 tion. For the user ID in Figure 273, TMUI should be used to maintain confidentiality of IMUI. In this case, TMUI assign- 
ment source ID should not be included in order to reduce data length. 

[0425] A TA SETUP PERMISSION request indication is issued by the TACF to inform to request the authorization of 
the mobile terminal access to the network. Figure 274 represents the detail of the TA SETUP PERMISSION request 
indication. 

20 [0426] A REVERSE LONG CODE RETRIEVAL request indication is used to retrieve a reverse (uplink) long code. Fig- 
ure 275 represents the detail of the REVERSE LONG CODE RETRIEVAL request indication. 
[0427] Another REVERSE LONG CODE RETRIEVAL request indication is used to retrieve the reverse long code. Fig- 
ure 276 represents the detail of the REVERSE LONG CODE RETRIEVAL request indication. 
[0428] A REVERSE LONG CODE RETRIEVAL response confirmation is also used to retrieve the reverse long code. 

25 Figure 277 represents the detail of the REVERSE LONG CODE RETRIEVAL response confirmation. 

[0429] A TERMINAL STATUS UPDATE request indication is used to update the terminal status. Figure 278 represents 
the detail of the TERMINAL STATUS UPDATE request indication. 

[0430] A TERMINAL STATUS UPDATE response confirmation is a response to the request indication. Figure 279 rep- 
resents the detail of the TERMINAL STATUS UPDATE response confirmation. 
30 [0431] An ADD- ROUTING INFORMATION request indication is sent to the LRDF to add a routing address to the sub- 
scriber's profile. This information flow is sent only when the authentic mobile terminal has been found and the above 
related information has been obtained. Figure 280 represents the detail of the ADD-ROUTING INFORMATION request 
indication. 

[0432] An ADD-ROUTING INFORMATION response confirmation is a response to the request indication. Figure 281 
35 represents the detail of the ADD-ROUTING INFORMATION response confirmation. 

[0433] A TA SETUP PERMISSION response confirmation is issued by the LRCF to inform the TACF that the mobile 
terminal access to the network is authorized. Figure 282 represents the detail of the TA SETUP PERMISSION 
response confirmation. 

[0434] A REVERSE LONG CODE RETRIEVAL response confirmation is used to retrieve the reverse long code. Fig- 
40 ure 283 represents the detail of the REVERSE LONG CODE RETRIEVAL response confirmation. 

[0435] A TA SETUP response confirmation is used to notify that the mobile terminal access has been established. 
Figure 284 represents the detail of the TA SETUP response confirmation. 

[0436] Another TA SETUP response confirmation is used to confirm that the setup of the terminal access and the 
connection between the CCAF and TACAF have been completed. Figure 285 represents the detail of the TA SETUP 
45 response confirmation. 

[0437] A SETUP request indication is used to request the establishment of the connection. Figure 286 represents the 
detail of the SETUP request indication. 

[0438] A TACF INSTANCE ID INDICATIONquest indication is used to retrieve the reverse long code. Figure 287 rep- 
resents the detail of the TACF INSTANCE ID INDICATIONquest indication. 
so [0439] A CELL CONDITION MEASUREMENT request indication is used by MRRC to trigger measurement of cell 
selection information. This is a requesting information flow whose confirmation (CELL CONDITION MEASUREMENT 
response confirmation) provides the resutt of the measurement. Figure 288 represents the detail of the CELL CONDI- 
TION MEASUREMENT request indication. 

[0440] A CELL CONDITION MEASUREMENT response confirmation provides the result of the cell selection infor- 
55 mation measurement requested by the CELL CONDITION MEASUREMENT request indication. Figure 289 represents 
the detail of the CELL CONDITION MEASUREMENT response confirmation. 

[0441] A CELL CONDITION REPORT request indication is used by the mobile terminal to report the cell selection 
information. The information is used by the network to select radio channels. This information flow does not require any 
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confirmation. Figure 290 represents the detail of the CELL CONDITION REPORT request indication. 
[0442] A CALL SETUP PERMISSION request indication is issued by the SSF to request the authorization of the call- 
ing user. Figure 291 represents the detail of the CALL SETUP PERMISSION request indication. 
[0443] A USER PROFILE RETRIEVAL request indication is used to request the user profile to be retrieved. Figure 
5 292 represents the detail of the USER PROFILE RETRIEVAL request indication. 

[0444] A USER PROFILE RETRIEVAL response confirmation is a response to the request indication. Figure 293 rep- 
resents the detail of the USER PROFILE RETRIEVAL response confirmation. 

[0445] A CALL SETUP PERMISSION response confirmation is issued by the LRCF to inform the calling user is 
authorized. Figure 294 represents the detail of the CALL SETUP PERMISSION response confirmation. 
70 [0446] A SETUP request indication is used to request the establishment of a connection. Figure 295 represents the 
detail of the SETUP request indication. 

[0447] A PROCEEDING request indication optionally reports that the indicated connection set-up is valid and author- 
ized and that further routing and progressing of the call is proceeding. This information flow does not require any con- 
firmation. Figure 296 represents the detail of the PROCEEDING request indication. 

15 [0448] A MEASUREMENT CONDITION NOTIFICATION request indication is transmitted at relationship rt between 
the TACF and the RRC and is used by the network to indicate conditions, which the mobile terminal measures, and to 
report the cell selection information. When the mobile terminal is on an idle mode, the network indicates the MEAS- 
UREMENT CONDITION NOTIFICATION request indication periodically. When the mobile terminal is in communication, 
the network indicates the MEASUREMENT CONDITION NOTIFICATION request indication at the change of condi- 

20 tions. This information flow does not require any confirmation. Figure 297 represents the detail of the MEASUREMENT 
CONDITION NOTIFICATION request indication. 

[0449] Another MEASUREMENT CONDITION NOTIFICATION request indication is transmitted at relationship rp 
between the MRRC and the RRC and is used by the network to indicate conditions, which the mobile terminal meas- 
ures, and to report cell selecting information. When the mobile terminal is on an idle mode, the network indicates the 
25 MEASUREMENT CONDITION NOTIFICATION request indication periodically. When the mobile terminal is in commu- 
nication, the network indicates the MEASUREMENT CONDITION NOTIFICATION request indication at the change of 
conditions. This information flow does not require any confirmation. Figure 298 represents the detail of the MEASURE- 
MENT CONDITION NOTIFICATION request indication. 

[0450] A REPORT request indication, at relationship r66 between a CCP and another CCF is an information flow that 
30 is used to report status and/or other types of information transported within the network. The type of information (e.g. 
alerting, suspended, hold, and resume) may be indicated. This information flow does not require any confirmation. Fig- 
ure 299 represents the detail of the REPORT request indication. 

[0451] Another REPORT request indication, at relationship ra between the CCAF and the CCF', is an information flow 
that is used to report the status information and/or other types of information transported within the network The type 
35 of information (e.g. alerting, suspended, hold, and resume) may be indicated. This information flow does not require any 
confirmation. Figure 300 represents the detail of the REPORT request indication. 

[0452] A SETUP response confirmation at relationship r66 is used to confirm that the connection has been estab- 
lished. Figure 301 represents the detail of the SETUP response confirmation. 

[0453] Another SETUP response confirmation at relationship ra is used to confirm that the connection has been 
40 established. Figure 302 represents the detail of the SETUP response confirmation. 

2.4.2.2 TERMINATION FOR INITIAL CALL AND ADDITIONAL CALL 

a) FUNCTIONAL MODEL 

a-1) INITIAL INCOMING CALL 

[0454] Figure 10 shows the functional model of a part of the invented system for describing the termination for initial 
call. 

a-2) ADDITIONAL INCOMING CALL 

[0455] Figure 1 1 shows the functional model of a part of the invented system for describing the termination for addi- 
tional call. 

55 
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INFORMATION FLOWS 



b-1) 



INITIAL INCOMING CALL 



5 [0456] 



Figures 12 through 14 form an information flow diagram showing the termination for initial call. 



b-2) 



ADDITIONAL INCOMING CALL 



[0457] 



Figures 15 and 16 form an information flow diagram showing the termination for additional call. 



10 



c) 

ACTIONS 



DEFINITIONS OF INFORMATION FLOWS, INFORMATION ELEMENTS, AND FUNCTIONAL ENTITY 



[0458] The information flow diagrams will be described supplementally in the following and information elements in 
is the flow diagrams will be discussed and represented in tables. 

[0459] A SETUP request indication is used to report the establishment of a connection. The detail is represented in 
Figure 303. 

[0460] A ROUTING INFORMATION QUERY request indication is used to inquire the routing information. The detail 
is represented in Figure 304. Either called user number or roaming number may be used as an identifier of the called 

20 user. Roaming number is used in this example represented in Figure 304. 

[0461] A TERMINAL ID RETRIEVAL request indication is used to request the user profile to be retrieved. The detail 
is represented in Figure 305. The roaming number item in Figure 305 is used in this information flow to specify the user 
whose profile should be retrieved, instead of the called user ID. The selection item in Figure 305 specifies the data 
which should be retrieved. This information element in this information flow specifies the user ID. 

25 [0462] A TERMINAL ID RETRIEVAL response confirmation is a response to the TERMINAL ID RETRIEVAL request 
indication. The detail is represented in Figure 306. 

[0463] A TERMINAL STATUS QUERY request indication is used to inquire the terminal status (e.g. if terminal access 
is active or not). The detail is represented in Figure 307. The selection item in Figure 307 specifies the data which 
should be retrieved. This information element in this information flow specifies the user's call status. 
so [0464] A TERMINAL STATUS QUERY response confirmation is a response to the TERMINAL STATUS QUERY 
request indication. The detail is represented in Figure 308. 

[0465] A TERMINAL STATUS UPDATE request indication is used to update the terminal status. The detail is repre- 
sented in Figure 309. 

[0466] A TERMINAL STATUS UPDATE response confirmation is a response to the TERMINAL STATUS UPDATE 
35 request indication. The detail is represented in Figure 310. 

[0467] A PAGING AREA QUERY request indication is used to inquire the paging area where TACF resides when it is 
observed that the terminal access is not active. The detail is represented in Figure 31 1 . The selection item represented 
in Figure 311 specifies the data which should be retrieved. This information element in this information flow specifies 
the paging area. 

40 [0468] A PAGING AREA QUERY response confirmation is a response to the PAGING AREA QUERY request indica- 
tion. The detail is shown in Figure 312. 

[0469] A PAGE request indication at relationship rg is used to trigger a TACF of paging. The detail of the PAGE request 
indication is represented in Figure 313. Paging relationship ID in Figure 313 is generated by the LRCF and is used to 
correlate the request and the response. 
45 [0470] A PAGING request indication at relationship rb is used to page a mobile terminal for determining its position in 
the network and for the routing for a call. This information flow requires a confirmation. The detail of the PAGING 
request indication is represented in Figure 314. The paging ID in Figure 314 is generated by the TACF and used to iden- 
tify the response. 

[0471 ] A PAGING response confirmation is used to respond to the request indication. The detail is represented in Fig- 
so ure315. 

[0472] A PAGE response confirmation is a response to the request indication and notifies the LRCF of the paging 
result LRCF initiates SLP for the user authentication of the responding user after receiving this information flow. The 
detail is represented in Figure 316. This information flow is also used in case of no response wherein if the optional 
information elements in Figure 316 are not read out, it is regarded that the paging request by the network is not 
55 responded by any terminals. 

[0473] A REVERSE LONG CODE RETRIEVAL request indication is used to retrieve a reverse (uplink) long code. The 
detail of the reverse long code at relationship rg is represented in Figure 317. 

[0474] Another REVERSE LONG CODE RETRIEVAL request indication is used to retrieve the reverse long code. The 
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detail of the reverse long code at relationship rd is represented in Figure 318. 

[0475] A REVERSE LONG CODE RETRIEVAL response confirmation is used to retrieve the reverse long code. The 
detail is represented in Figure 319. 

[0476] A CELL CONDITION MEASUREMENT request indication is used by the MRRC to trigger the measurement 
5 of cell selecting information. This information flow requires a confirmation. The confirmation (CELL CONDITION MEAS- 
UREMENT response confirmation) provides the result of the measurement. The detail of the CELL CONDITION 
MEASUREMENT request indication is represented in Figure 320. 

[0477] A CELL CONDITION MEASUREMENT response confirmation provides the result of the cell selection infor- 
mation measurement requested by the CELL CONDITION MEASUREMENT request indication. The detail of the CELL 
w CONDITION MEASUREMENT response confirmation is represented in Figure 321. 

[0478] A CELL CONDITION REPORT request indication is used by the mobile terminal to report the cell selection 
information. The information is used by the network to select radio channels. This information flow does not require any 
confirmation. The detail is represented in Figure 322. 

[0479] An ADD-ROUTING INFORMATION request indication is sent to the LRDFp to add the routing information to 
is the subscriber's profile. This information flow is only sent when the authentic mobile terminal has been found and the 
above related information has been obtained. The detail is represented in Figure 323. 

[0480] An ADD-ROUTING INFORMATION response confirmation is a response to the ADD-ROUTING INFORMA- 
TION request indication. The detail of the ADD-ROUTING INFORMATION response confirmation is represented in Fig- 
ure 324. 

20 [0481 ] A PAGE AUTHORIZED request indication at relationship rg is used to notify the TACF of the result of the ter- 
minal authentication. The detail is represented in Figure 325. 

[0482] A REVERSE LONG CODE RETRIEVAL response confirmation is used to retrieve the reverse long code. The 
detail is represented in Figure 326. 

[0483] A PAGE AUTHORIZED request indication is used to notify the TACF of the result of the terminal authentication. 
25 [0484] A ROUTING INFORMATION QUERY response confirmation is a response to the request indication. The detail 
is represented in Figure 327. The routing address item and TACF instance ID item in Figure 327 are used in this case 
to specify the routing information. The routing address item is used fa routing in the visited network. 
[0485] A SETUP request indication is used to request the establishment of a connection. The detail is represented in 
Figure 328. 

30 [0486] A TERMINATION ATTEMPT request indication is used to request the user's profile which may be needed to 
proceed the call process. The detail is represented in Figure 329. 

[0487] A USER PROFILE RETRIEVAL request indication is used to retrieve the called user's profile from the LRDF. 
The detail is represented in Figure 330. 

[0488] A USER PROFILE RETRIEVAL response confirmation is a response to the request indication from the LRCF. 
35 The detail is represented in Figure 331 . 

[0489] A TERMINATION ATTEMPT response confirmation is a response to the request indication from the SSF. The 
detail is represented in Figure 332. 

[0490] A SETUP request indication is used to request the establishment of a connection. The detail is represented in 
Figure 333. 

40 [0491] A PROCEEDING request indication optionally reports that the instructed connection setup is valid and authen- 
ticated and that further routing and progressing of the call is proceeding. This information flow does not require any con- 
firmation. The detail is represented in Figure 334. 

[0492] A MEASUREMENT CONDITION NOTIFICATION request indication is used by the network to indicate condi- 
tions, which the mobile terminal measures, and to report the cell selection information. When the mobile terminal is on 

45 an idle mode, the network indicates the MEASUREMENT CONDITION NOTIFICATION request indication periodically. 
When the mobile terminal is in communication, the network indicates the MEASUREMENT CONDITION NOTIFICA- 
TION request indication at the change of conditions. This information flow does not require any confirmation. The detail 
of the MEASUREMENT CONDITION NOTIFICATION request indication is represented in Figure 335. 
[0493] A REPORT request indication is an information element that is used to report status and/or other types of infor- 

50 mation transported in the network. The type of information may be indicated (e.g. alerting, suspended, hold, resume). 
This information flow does not require any confirmation. The detail of the REPORT request indication is represented in 
Figure 336. 

[0494] A SETUP response confirmation is used to confirm that the connection has been established. The detail is 
represented in Rgure 337. 

55 [0495] A CONNECTED request indication is used to acknowledge that a previously sent SETUP response confirma- 
tion has been received and accepted. This information flow does not require any confirmation. The detail is represented 
in Figure 338. 
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2.4.2.3 CALL RELEASE 

2.4.2.3.1 DISCONNECTION INSTRUCTED BY USER 

5 (a) FUNCTIONAL MODEL 

[0496] Figure 17 shows the functional model of a part of the invented system for describing the disconnection 
instructed by a user. 

10 (b) INFORMATION FLOWS 

[0497] Figure 18 is an information flow diagram showing the disconnection instructed by a user. 

(c) DEFINITIONS OF INFORMATION FLOWS 

15 

[0498] A RELEASE request indication is used to release resources associated with a call connection, such as call ID 
or channels. This information flow requires a confirmation. The detail is represented in Figure 339. 
[0499] A RELEASE response confirmation is used to indicate that all resources pervasively associated with the con- 
nection have been released. The detail is represented in Figure 340. 
20 [0500] A TA RELEASE request indication is issued by the TACF to inform the SCF that an attempt of call release has 
been detected. This information flow is issued when the last call is released and the control relationship between the 
terminal and the network should be released. The detail is represented in Figure 341 . 

[0501] A TERMINAL-STATUS-MAKE-IDLE request indication is used to idle the terminal call status. The detail is rep- 
resented in Figure 342. 

25 [0502] A TERM INAL-STATUS-MAKE-IDLE response confirmation is a response to the TERMINAL-STATUS-MAKE- 
IDLE request indication. The detail of the TERMINAL-STATUS-MAKE-IDLE response confirmation is represented in 
Figure 343. 

[0503] A TA RELEASE response confirmation is used for the confirmation to the TA RELEASE request indication. The 
detail of the TA RELEASE response confirmation is represented in Figure 344. 

30 

2.4.2.3.2 DISCONNECTION INSTRUCTED BY NETWORK 

(a) FUNCTIONAL MODEL 

35 [0504] Figure 19 shows the functional model of a part of the invented system for describing the disconnection 
instructed by the network. 

(b) INFORMATION FLOWS 

40 [0505] Figure 20 is an information flow diagram showing the disconnection instructed by the network. 

(c) DEFINITIONS OF INFORMATION FLOWS 

[0506] The information flow diagram will be described supplementally in the following and information elements in the 

45 flow diagram will be discussed and represented in tables. 

[0507] A RELEASE request indication is used to release resources associated with a call connection such as the call 
reference or channels. This information flow requires a confirmation. The detail is represented in Figure 345. 
[0508] A RELEASE response confirmation is used to indicate that ail resources previously associated with the con- 
nection have been released. The detail is represented in Figure 346. 

so [0509] A TA RELEASE request indication is issued by the TACF to inform the LRCF that an attempt of call release 
has been detected. This information flow is issued when the last call is released and the control relationship between 
the terminal and the network should be released. The detail is represented in Figure 347. 

[0510] A TERMINAL-STATUS-MAKE-IDLE request indication is used to idle the terminal call status. The detail is rep- 
resented in Figure 348. 

55 [051 1 ] A TERMINAL-STATUS-MAKE-IDLE response confirmation is a response to the TERM INAL-STATUS-MAKE- 
IDLE request indication. The detail is represented in Figure 349. 

[0512] A TA RELEASE response confirmation is used for the response confirmation of the TERMINAL-STATUS- 
MAKE-IDLE request indication. The detail is represented in Figure 350. 
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2.4.2.3.3 ABNORMAL RELEASE 

2.4.2.3.3.1 ABNORMAL RELEASE CAUSED FROM RADIO LINK FAILURE DETECTED BY MOBILE TER- 

MINAL 

5 

2.4.2.3.3.1.1 COMMON PROCEDURE MODULE USED 

[051 3] A common procedure module used in this release process is the "user disconnect." 
w 2.4.2.3.3.1.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

[0514] Figure 21 shows the functional model of a part of the invented system for describing the abnormal release 
75 caused from a radio link failure (squelch condition) detected by a mobile terminal. 

b) INFORMATION FLOWS 

[051 5] Figure 22 shows an information flow diagram of the abnormal release, executed in the communication control 
20 plane, caused from the radio link failure detected by the mobile terminal. 

C) DEFINITIONS OF INFORMATION FLOWS AND INFORMATION ELEMENTS 

[0516] Information flows in Figure 22 will be described below and information elements of the flows are represented 
25 in tables. The order of description is the same as the order of the flows in Figure 22. 

[0517] A RADIO LINK FAILURE request indication is used to notify a radio link failure detected by the BCAF or BCFr. 

In this flow procedure, this information flow is issued by the BCAF. The detail is represented in Figure 351 . 

[0518] A RELEASE NOTIFICATION request indication is used to indicate that the connection between the network 

and the terminal has been released. The information flow does not require any confirmation. The detail is represented 
30 in Figure 352. 

[0519] A RADIO LINK FAILURE request indication is used to notify that the link failure has been detected. The detail 
is represented in Figure 353. 

[0520] Another RADIO LINK FAILURE request indication is used to notify that the link failure has been detected. The 
detail is represented in Figure 354. 
35 [0521] A RADIO LINK FAILURE response confirmation is a response confirmation of the RADIO LINK FAILURE 
request indication. The detail is represented in Figure 355. 

[0522] A RADIO BEARER RELEASE request indication is used to request to release radio bearers. This is originated 
by network. The detail is represented in Figure 356. 

[0523] A TA RELEASE request indication is issued by the TACF to request the release of terminal access. This infor- 
40 mation flow is issued for only the last call release. 

[0524] A BEARER RELEASE request indication is issued by the TACF to the BCF to release the radio bearer. The 
detail is represented in Figure 357. 

[0525] A BEARER RELEASE response confirmation is a response confirmation of the bearer release request indica- 
tion. The detail is represented in Figure 358. 
45 [0526] Another BEARER RELEASE request indication is sent by the anchor TACF to request the serving TACF to 
release the bearer involved in the call that should be released. The detail is represented in Figure 359. 
[0527] Another BEARER RELEASE request indication is issued by the TACF to BCF to release the radio bearer. The 
detail is represented in Figure 360. 

[0528] Another BEARER RELEASE response confirmation is a response confirmation of the BEARER RELEASE 
so request indication. The detail is represented in Figure 361 . 

[0529] A BEARER-AND-RADIO-BEARER RELEASE request indication is issued by the TACF to release the bearer- 
and-radio-bearer. The detail is represented in Figure 362. 

[0530] A BEARER-AND-RADIO-BEARER RELEASE response confirmation is used for a confirmation of the release 
of the bearer-and-radio-bearer requested by the BEARER-AND-RADIO-BEARER RELEASE request indication. The 
55 detail is represented in Figure 363. 

[0531] Another BEARER RELEASE response confirmation is a confirmation response to inform the TACF that the 

previous request to release the radio bearer has been completed. The detail is represented in Figure 364. 

[0532] A TA RELEASE request indication is issued by the TACF to inform the LRCF that the attempt of releasing call 



60 



EP0978 958A1 



has detected. The detail is represented in Figure 365. 

[0533] A TERMINAL-STATUS-MAKE -IDLE request indication is used to request to update the user profile. For call 
release, this information flow is used to update the user's call status to idle. The detail is represented in Figure 366. 
[0534] A TERMINAL-STATUS-MAKE-IDLE response confirmation is a response to the TERMINAL-STATUS-MAKE- 
5 IDLE request indication. The detail is represented in Figure 367. 

[0535] A TA RELEASE response confirmation is used for a response confirmation of the TA RELEASE request indi- 
cation. The detail is represented in Figure 368. 

2.4.2.3.3.2 ABNORMAL RELEASE CAUSED FROM RADIO LINK FAILURE DETECTED BY NETWORK 

10 

2.4.2.3.3.2.1 COMMON PROCEDURE MODULE USED 

[0536] A common procedure module used in this release process is the "user disconnect." 
15 2.4.2.3.3.2.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

[0537] Figure 23 shows the functional model of a part of the invented system for describing the abnormal release 
20 caused from a radio link failure (squelch condition) detected by the network. 

b) INFORMATION FLOWS 

[0538] Figure 24 shows an information flow diagram of the abnormal release, executed in the communication control 
25 plane, caused from the radio link failure detected by the network. 

c) DEFINITIONS OF INFORMATION FLOWS AND INFORMATION ELEMENTS 

[0539] Information flows in Figure 24 will be described below and information elements of the flows are represented 
30 in tables. The order of description is the same as the order of the flows in Figure 24. 

[0540] A RADIO LINK FAILURE request indication is used to notify that a link failure has been detected and reported 
by either BCFr or BCFa. The detail is represented in Figure 369. 

[0541] Another RADIO LINK FAILURE request indication is used to notify that the link failure has been detected. The 
detail is represented in Figure 370. 
35 [0542] A RADIO LINK FAILURE response confirmation is a confirmation response to the RADIO LINK FAILURE 
request indication. The detail is represented in Figure 371. 

[0543] A RADIO BEARER RELEASE request indication is used to request to release the radio bearer. This is origi- 
nated by the network. The detail is represented in Figure 372. 

[0544] A RELEASE NOTIFICATION request indication is used to indicate that the connection between the network 
40 and the terminal has been released. The information flow does not require any confirmation. The detail is represented 
in Figure 373. 

[0545] A RADIO BEARER RELEASE response confirmation is a response confirmation of the RADIO BEARER 
RELEASE request indication. The detail is represented in Figure 374. 

[0546] A TA RELEASE request indication is issued by the TACF to request the release of terminal access. This infor- 
ms mation flow is issued for only the last call. 

[0547] A TA RELEASE response confirmation is a response confirmation of the TA RELEASE request indication. 
[0548] A BEARER RELEASE request indication is issued by the TACF to BCF to release the radio bearer. The detail 
is represented in Figure 375. 

[0549] A BEARER RELEASE response confirmation is a response confirmation of the BEARER RELEASE request 
so indication. The detail is represented in Figure 376. 

[0550] Another BEARER RELEASE request indication is sent by the anchor TACF to request the serving TACF to 

release the radio bearer involved in the call that should be released. The detail is represented in Figure 377. 

[0551 ] Another BEARER RELEASE request indication is issued by the TACF to BCF to release the radio bearer. The 

detail is represented in Figure 378. 
55 [0552] A BEARER RELEASE response confirmation is a response confirmation of the BEARER RELEASE request 

indication. The detail is represented in Figure 379. 

[0553] A BEARER-AND-RADIO-BEARER RELEASE request indication is issued by the TACF to release the bearer- 
and-radio-bearer. The detail is represented in Figure 380. 
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[0554] A BEARER-AND-RADIO-BEARER RELEASE response confirmation is used for a confirmation of the release 
of the bearer and radio bearer requested by the BEARER-AND-RADIO-BEARER RELEASE request indication. The 
detail is represented in Figure 381 . 

[0555] Another BEARER RELEASE response confirmation is a confirmation response for informing the TACF that the 
s previous request to release the radio bearer has been completed. The detail is represented in Figure 382. 

[0556] A RADIO BEARER RELEASE request indication is issued to request to release the radio bearer. The detail is 
represented in Figure 383. 

[0557] Another RADIO BEARER RELEASE response confirmation is used to confirm the release of radio bearer 
requested by the RADIO BEARER RELEASE request indication. The detail is represented in Figure 384, 
10 [0558] A TA RELEASE request indication is issued by the TACF to inform the LRCF that the attempt of call release 
has been detected. The detail is represented in Figure 385. 

[0559] A TE RM I N AL-STATUS-M AKE- 1 D LE request indication is used to request to update the user profile. For call 
release, this information flow is used to update the user's call status to idle. The detail is represented in Figure 386. 
[0560] A TERMINAL-STATUS-MAKE- IDLE response confirmation is a response to the TERM IN AL-STATUS-M AKE- 
15 IDLE request indication. The detail is represented in Figure 387. 

[0561] Another TA RELEASE response confirmation is used for confirmation to the TA RELEASE request indication. 
The detail is represented in Figure 388. 



20 



2.4.2.3.4 USER DISCONNECT 

2.4.2.3.4.1 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

25 [0562] Figure 25 shows the functional model of a part of the invented system for describing the "user disconnect." 

b) INFORMATION FLOWS 

[0563] Figure 26 shows an information flow diagram of the "user disconnect." 

c) DEFINITIONS OF INFORMATION FLOWS AND INFORMATION ELEMENTS 



30 



[0564] Information flows in Figure 26 will be described below and information elements in the flows are represented 
in tables. The order of description is the same as the order of the flows in Figure 26. 
35 [0565] A CALL DISCONNECT request indication is used to notify the LRCF that a "user disconnect" has been 
detected. The detail is represented in Figure 389. 

[0566] A USER-PROFILE-UPDATE request indication is used to request to update the user profile. For call release, 
this information flow is used to indicate the call has been released. The detail is represented in Figure 390. 
[0567] A USER-PROFILE-UPDATE response confirmation is a response to the USER-PROFILE-UPDATE response 
40 confirmation. The detail is represented in Figure 391 . 

[0568] A CALL DISCONNECT response confirmation is a response to the request made by the CALL DISCONNECT 
request indication. The detail is represented in Figure 392. 



45 



2.4.3 INFORMATION FLOW DIAGRAMS FOR ACCESS LINK CONTROL 

2.4.3.1 SDCCH SETUP 

[0569] First, the SDCCH setup process will be described. 
so 2.4.3.1.1 COMMON PROCEDURE MODULES USED 

2.4.3.1 .2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 



55 



[0570] Figure 27 shows the functional model of a part of the invented system for describing the SDCCH setup proc- 
ess. 
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b) INFORMATION FLOWS 

[0571 ] Figure 28 shows an information flow diagram of the SDCCH setup process. 

5 c) DEFINITIONS OF INFORMATION FLOWS AND INFORMATION ELEMENTS 

[0572] Information flows in Figure 28 will be described below and information elements of the flows are represented 
in tables. The order of description is the same as the order of the flows in Figure 28. 

[0573] A SIGNALING CHANNEL SETUP REQUEST request indication is used by the MCF and TACF to request the 
w network to setup the signaling channels. The detail is represented in Figure 393. 

[0574] A SIGNALING CHANNEL SETUP request indication is used by the SCMAF to request to the network to allo- 
cate the signaling channels. The detail is represented in Figure 394. 

[0575] A SIGNALING CHANNEL SETUP response confirmation is used by the SCMF to allocate the radio resources 
to the signaling channels. The detail is represented in Figure 395. 
15 [0576] A SIGNALING CHANNEL SETUP REQUESTED request indication is used to indicate the reception of the sig- 
naling channel setup request (initial access detection) from the mobile terminal and to request the network to setup the 
corresponding signaling channels in the network. The detail is represented in Figure 396. 

[0577] A SIGNALING CONNECTION SETUP request indication is used by the TACF and SACF to setup the signaling 
connection among them and the SCMF The detail is represented in Figure 397. 
20 [0578] A SIGNALING CONNECTION SETUP response confirmation is used to report the establishment of the sign- 
aling channels including the physical radio channel and the intra-network channel. The detail is represented in Figure 
398. 

[0579] A SIGNALING CHANNEL SETUP REQUEST response confirmation is used by the SCMAF to report the setup 
of the signaling channels to the network. The detail is represented in Figure 399. 

25 

2.4.3.2 BEARER SETUP 

[0580] Next, bearer setup procedures for the radio resource selection will be described, 
30 2.4.3.2.1 COMMON PROCEDURE MODULES USED 

2.4.3.2.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

35 

[0581 ] Radio resources are selected under a base station which is different from the one that received a call setup 
request from a mobile terminal while the BSs are controlled by different TACFs. The CCF only has the relationship with 
the TACFa and does not have the relationship with the TACFv. The TACFa controls both bearer selection and bearer 
setup. There are three BCFs: BCF1 , BCF2, and BCFr. 
40 [0582] Figure 29 shows the functional model of a part of the invented system for describing the bearer setup for the 
radio resource selection. 

b) INFORMATION FLOWS 

45 [0583] Figure 30 shows an information flow diagram of the bearer setup, executed in the communication control plane, 
for the radio resource selection. 

2.4.3.2.2.3 DEFINITIONS OF INFORMATION FLOWS AND INFORMATION ELEMENTS 

so [0584] Information flows in Figure 30 will be described below and information elements of the f tows are represented 
in tables. The order of description is the same as the order of the flows in Figure 30. 

[0585] A BEARER SETUP request indication is used to request the establishment of the access bearer from the CCF 
to TACF. The detail is represented in Figure 400. The information elements asterisked in Figure 400 are contained in 
the bearer capability element in Figure 286 sent from the CCAF. 
55 [0586] A CHANNEL SELECTION request indication is used by the TACF to request to select and reserve radio 
resources which can support the required bearer capability. This interaction occurs when new radio resources are nec- 
essary for call setup and handover. 

[0587] A CHANNEL SELECTION response confirmation is used to report the reserved radio resources to the TACF, 
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which requested the reservation. The detail is represented in Figure 401. 

[0588] A BEARER SETUP request indication is sent from the TACF to BCF to request the establishment of the access 
bearer. The detail is represented in Figure 402. 

[0589] A BEARER SETUP response confirmation is sent to confirm the establishment of the access bearer and to 
indicate the bearer ID of the bearer between the BCF and BCF. The detail is represented in Figure 403. 
[0590] Another BEARER SETUP request indication is used to request the establishment of the access bearer from 
the TACFa to TACF v. The detail is represented in Figure 404. 

[0591 ] Another BEARER SETUP request indication is sent from the TACF to BCF to request the establishment of the 
access bearer. The detail is represented in Figure 405. 

[0592] Another BEARER SETUP response confirmation is sent from the BCF to TACF to request the establishment 
of the access bearer. The detail is represented in Figure 406. 

[0593] A BEARER-AND-RADIO-BEARER SETUP request indication is sent from the TACF to BCFr to request the 
establishment of the radio bearer and the bearer between the BCF and BCFr. The detail is represented in Figure 407. 
[0594] A RADIO BEARER SETUP PROCEEDING request indication is used by the BCFr to report that the instructed 
radio bearer setup is valid and the establishment of the radio bearer is proceeding. This information flow does not 
require any confirmation. The detail is represented in Figure 408. 

[0595] A RADIO BEARER SETUP REQUEST request indication is issued by the TACF, which controls a new access 
bearer, to the TACF, which has the signaling connection, to request to newly assign a radio bearer to the mobile termi- 
nal. The detail is represented in Figure 409. 

[0596] A RADIO BEARER SETUP request indication is sent from the TACF to TACAF to request the establishment 
of the radio bearer. The detail is represented in Figure 410. 

[0597] Another RADIO BEARER SETUP request indication is sent from the TACAF to BCAF to request the establish- 
ment of the radio bearer. The detail is represented in Figure 41 1 . 

[0598] A RADIO BEARER SETUP response confirmation is sent from the BCAF to TACAF to confirm that the estab- 
lishment of radio bearer has been completed. The detail is represented in Figure 412. 

[0599] A BEARER-AND-RADIO-BEARER SETUP response confirmation is sent to confirm that the establishment of 
radio bearer and bearer between the BCF and BCFr have been completed. The detail is represented in Figure 413. 
[0600] A BEARER SETUP response confirmation is used to confirm that the establishment of access bearer has been 
completed. The detail is represented in Figure 414. 

[0601] Another BEARER SETUP response confirmation is used to confirm that the establishment of access bearer 
has been completed. The detail is represented in Figure 415. 

2.4.3.3 RADIO BEARER RELEASE 

2.4.3.3.1 RADIO BEARER RELEASE FOR TACF ANCHOR APPROACH 

2.4.3.3.1.1 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

[0602] Figure 31 shows the functional model of a part of the invented system for describing the radio bearer release. 

b) INFORMATION FLOWS 

[0603] Figure 32 shows an information flow diagram of the radio bearer release. 

2.4.3.3.1 .2 DEFINITIONS OF INFORMATION FLOWS AND INFORMATION ELEMENTS 

[0604] Information flows in Figure 32 will be described below and information elements of the flows are represented 
in tables. The order of description is the same as the order of the flows in Figure 32. 

[0605] A BEARER RELEASE request indication is sent by the anchor CCF to notify the anchor TACF that the attempt 
or event of call release has been detected and that the bearer involved in the call is being released. The detail is repre- 
sented in Figure 416. 

[0606] A RADIO BEARER RELEASE request indication is used by the TACFa to request to release the radio bearer. 
This is originated by the network The detail is represented in Figure 41 7. 

[0607] A RADIO BEARER RELEASE response confirmation is a response confirmation of the RADIO BEARER 
RELEASE request indication. The detail is represented in Figure 418. 

[0608] A TA RELEASE request indication is issued by the TACFa to request the release of the terminal access. This 
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information flow is issued only for the last call release. 

[0609] A TA RELEASE response confirmation is a response confirmation of the TA RELEASE request indication. 
[0610] A BEARER RELEASE request indication is issued by the TACF to BCF to release the radio bearer. The detail 
is represented in Figure 41 9. 

5 [061 1] A BEARER RELEASE response confirmation is a response confirmation of the BEARER RELEASE request 
indication. The detail is represented in Figure 420. 

[0612] Another BEARER RELEASE request indication is sent by the TACFa to request the TACFv to release the 
bearer involved in the call is being released. The detail is represented in Figure 421. 

[0613] Another BEARER RELEASE request indication is issued by the TACF to BCF to release the radio bearer. The 
10 detail is represented in Figure 422. 

[0614] A BEARER RELEASE response confirmation is a response confirmation of the BEARER RELEASE request 
indication. The detail is represented in Figure 423. 

[061 5] A BEARER-AND-RADIO-BEARER RELEASE request indication is issued by the TACF to release the bearer 
and radio bearer. The detail is represented in Figure 424. 
is [061 6] A BEARER-AND-RADIO-BEARER RELEASE response confirmation is used for a confirmation 6f the release 
of the bearer and radio bearer requested by the BEARER-AND-RADIO-BEARER RELEASE request indication. The 
detail is represented in Figure 425. 

[061 7] Another BEARER RELEASE response confirmation is a confirmation of the BEARER RELEASE' request indi- 
cation. The detail is represented in Figure 426. 
20 [061 8] Another BEARER RELEASE response confirmation is a response confirmation to inform the CCF that the pre- 
vious request to release the radio bearer has been completed. The detail is represented in Figure 427. 1 
[0619] Another RADIO BEARER RELEASE request indication is issued by the TACAF to request the radio bearer 
release. The detail is represented in Figure 428. 

[0620] Another RADIO BEARER RELEASE request indication is used by the BCAF to confirm the radio bearer 
25 release requested by the RADIO BEARER RELEASE request indication. The detail is represented in Figure 429. 

2.4.3.4 SDCCH RELEASE 

[0621 ] Next, SDCCH release procedures will be described. 

30 

2.4.3.4.1 COMMON PROCEDURE MODULES USED 

2.4.3.4.2 INFORMATION FLOW DIAGRAM 
35 a) FUNCTIONAL MODEL 

[0622] Figure 33 shows the functional model of a part of the invented system for describing the SDCCH release, 
b) INFORMATION FLOWS 

40 

[0623] Figure 34 shows an information flow diagram of the SDCCH release. 

2.4.3.4.3 DEFINITIONS OF INFORMATION FLOWS AND INFORMATION ELEMENTS 

45 [0624] Information flows in Figure 34 will be described below and information elements of the flows are 1 represented 
in tables. The order of description is the same as the order of the flows in Figure 34. 

[0625] A SIGNALING CHANNEL RELEASE REQUEST request indication is used by the MCF and TACF to request 
the release of a signaling channel. The detail is represented in Figure 430. ? 
[0626] A SIGNALING CONNECTION RELEASE request indication is used by the TACF and SACF to request the 
so release of the signaling channel (in both of the network and the radio resources). The detail is represented in Figure 
431. 

[0627] A SIGNALING CONNECTION RELEASE response confirmation is used to report the release of the signaling 
channel. The detail is represented in Figure 432. 
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2.4.3.5 HANDOVER 

2.4.3.5.0 HANDOVER PROCESS AND RELEVANT PROCEDURE MODULES 

5 Process 1 : Handover trigger 

[0628] Detection of handover triggering. 
Process 2: Handover resource reservation 

10 

[0629] Reservation of radio resources for handover. 

Process 3: Handover execution 

15 [0630] Preparing at network side, if any. 

[0631] Request the mobile terminal as indicated by trigger. 

Process 4: Handover completion 

20 [0632] Release of unneeded radio bearer and resources. 

[0633] Figure 35 shows a f tow chart showing handover processes in general. Figure 36 is an information flow diagram 
showing processes 1 and 2 described above. 

[0634] Figure 37 is an information flow diagram representing a sequence in which information flows are transported 
for starting non-soft handover execution, the sequence corresponding to process 1 in Figure 35. Figure 38 is an infor- 
ms mation flow diagram representing a sequence in which information flows are transported for starting handover branch 
addition, the sequence corresponding to process 1 in Figure 35. Figure 39 is an information flow diagram representing 
a sequence in which information flows are transported for starting handover branch deletion, the sequence correspond- 
ing to process 1 in Figure 35. 

30 2.4.3.5.1 INTER-SECTOR HANDOVER BRANCH ADDITION IN SINGLE CELL 

(HANDOVER CONTROLLED BY SAME BCFr) 

2.4.3.5.1.1 COMMON PROCEDURE MODULES 

35 2.4.3.5.1.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

[0635] Figure 40 shows the functional model of a part of the invented system for describing the inter-sector handover 
40 branch addition in a single cell. 

b) INFORMATION FLOWS 

[0636] Figure 41 shows an information flow diagram of the inter-sector handover branch addition in a single cell, exe- 
45 cuted in the communication control plane. 

2.4.3.5.1.3 DEFINITIONS OF INFORMATION FLOWS AND INFORMATION ELEMENTS 

[0637] Information flows in Figure 41 will be described below and information elements of the flows are represented 
so in tables. 

[0638] A BEARER SETUP request indication is sent from the TACFa to TACFv to request the setup of an access 
bearer. The detail is represented in Figure 433. This information flow identifies the bearer between the BCFa and BCFv. 
[0639] An INTRA- BCFr HANDOVER BRANCH ADDITION request indication is sent from the TACF to BCFr to request 
to setup new physical radio channel(s). The detail is represented in Figure 434. 
55 [0640] An INTRA-BCFr HANDOVER BRANCH ADDITION response confirmation is a response to the INTRA-BCFr 
HANDOVER BRANCH ADDITION request indication and is sent from the BCFr to TACF to indicate the completion of 
setup ol the physical radio channel(s). The detail is represented in Figure 435. 

[0641] A RADIO BEARER SETUP REQUEST request indication is sent from the visited TACF, which controls the 
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newly assigned radio bearer, to TAG Fa to request to setup the radio bearer between the mobile terminal and BCFr con- 
trolled by the visited TACF. The detail is represented in Figure 436. 

[0642] A HANDOVER BRANCH ADDITION request indication is sent from the TACF to TACAF to notify of the intra- 
BCFr handover branch addition, and requests to add a new physical radio channel to an existing physical radio channel. 
5 The detail is represented in Figure 437. The information element marked by *1 in Figure 437 may be repeated a plurality 
of times, the number of repetition is the same as the number of the handover branches at the mobile terminal. The infor- 
mation elements marked by *2 in Figure 437 may be repeated a plurality of times, the number of repetition is the same 
as the number of the calls related to the TACF 

[0643] A HANDOVER BRANCH ADDITION response confirmation is sent from the TACAF to TACF to notify of the 
10 reception of the HANDOVER BRANCH ADDITION request indication. 

[0644] A RADIO BEARER SETUP request indication is sent from the TACAF to BCAF to request to setup a radio 
bearer The detail is represented in Figure 438. 

[0645] A RADIO BEARER SETUP response confirmation is a response to the RADIO BEARER SETUP request indi- 
cation sent from the BCAF to TACAF to indicate the completion of the radio bearer setup. The detail is represented in 
15 Figure 439. 



20 



2.4.3.5.2 INTER-CELL HANDOVER BRANCH ADDITION 

2.4.3.5.2.1 COMMON PROCEDURE MODULES 

2.4.3.5.2.2 INFORMATION FLOW DIAGRAM 



a) FUNCTIONAL MODEL 

25 [0646] Figure 42 shows the functional model of a part of the invented system for describing the inter-cell handover 
branch addition. 



b) INFORMATION FLOWS 



30 [0647] Figure 43 shows an information flow diagram of the inter-cell handover branch addition, executed in the com- 
munication control plane. 

2.4.3.5.2.3 DEFINITIONS OF INFORMATION FLOWS AND INFORMATION ELEMENTS 

35 [0648] A HANDOVER CONNECTION SETUP request indication is sent from the TACFa to BCFa to notify of a hando- 
ver initiation and to request to setup an access bearer. The detail is represented in Figure 440. The information element 
marked by *1 in Figure 440 identifies the bearer between the CCF and BCF. 

[0649] A HANDOVER CONNECTION SETUP response confirmation is sent from the BCF to TACF to confirm the 
HANDOVER CONNECTION SETUP request indication. The detail is represented in Figure 441. The asterisked infor- 
40 mation element in Figure 441 identifies the bearer between the BCFa and BCFv. 

[0650] A BEARER SETUP request indication is sent from the TACFa to TACFv to setup an access bearer. The detail 
is represented in Figure 442. The asterisked information element in Figure 442 identifies the bearer between the BCFa 
and BCFv 

[0651] Another BEARER SETUP request indication is sent from the TACF to BCF to request the bearer setup. The 
45 detail is represented in Figure 443. The asterisked information element in Figure 443 identifies the bearer between the 
BCF and CCF. 

[0652] A BEARER SETUP response confirmation is sent from the BCF to TACF to confirm the BEARER SETUP 
request indication. The detail is represented in Figure 444. The asterisked information element in Figure 444 identifies 
the bearer between the BCF and BCFr. 

so [0653] A BEARER-AND-RADIO-BEARER SETUP request indication is sent from the TACF to BCFr to request to 
setup a bearer between the BCF and BCFr and a radio bearer. The detail is represented in Figure 445. 
[0654] A BEARER-AND-RADIO-BEARER SETUP response confirmation is a response to the BEARER-AND- 
RADIO-BEARER SETUP request indication and is sent from the BCFr to TACF to indicate the completion of setting up 
of the radio bearer and bearer between the BCFr and BCF. The detail is represented in Figure 446. 

ss [0655] A RADIO BEARER SETUP REQUEST request indication is sent from the visited TACF, which controls the 
newly assigned radio bearer, to the TACFa to request to setup the radio bearer between the mobile terminal and BCFr. 
The detail is represented in Figure 447. 

[0656] A HANDOVER BRANCH ADDITION request indication is sent from the TACF to TACAF to notify of the 
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HANDOVER BRANCH ADDITION request indication and to request to setup a new physical radio channel(s) without 
releasing the existing physical radio channel(s). The detail is represented in Figure 448. The information elements 
marked by *1 in Figure 448 maybe repeated a plurality of times, the number of repetition is the same as the number of 
the destination cells. The information elements marked by *2 in Figure 448 maybe repeated a plurality of times, the 
5 number of repetition is the same as the number of the calls related to the TACF. 

[0657] A HANDOVER BRANCH ADDITION response confirmation is sent from the TACAF to TACF to notify of the 
reception of the HANDOVER BRANCH ADDITION INITIATION request indication. 

[0658] A RADIO BEARER SETUP request indication is sent from the TACAF to BCAF to request to setup a radio 
bearer. The detail is represented in Figure 449. 
w [0659] A RADIO BEARER SETUP response confirmation is a response to the RADIO BEARER SETUP request indi- 
cation and is sent from the BCAF to TACAF to indicate the completion of the radio bearer setup. The detail is repre- 
sented in Figure 450. 

[0660] A BEARER SETUP response confirmation is sent from the TACFa to TACFv to confirm the establishment of 
the access bearer. The detail is represented in Figure 451 . 

15 

2.4.3.5.3 INTER-SECTOR HANDOVER BRANCH DELETION IN SINGLE CELL (HANDOVER CONTROL- 

LED BY SAME BCFr) 

2.4.3.5.3. 1 COMMON PROCEDURE MODULES 

20 

2.4.3.5.3.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

25 [0661 ] Figure 44 shows the functional model of a part of the invented system for describing the inter-sector handover 
branch deletion in a single cell. 

b) INFORMATION FLOWS 

30 [0662] Figure 45 shows an information flow diagram of the inter-sector handover branch deletion in a single cell, exe- 
cuted in the communication control plane. 

2.4.3.5.3.3 DEFINITIONS OF INFORMATION FLOWS AND INFORMATION ELEMENTS 

35 [0663] A HANDOVER BRANCH DELETION request indication is sent from the TACF to TACAF to request to release 
the physical radio channel(s). The detail is represented in Figure 452. The information elements marked by *1 in Figure 
452 may be repeated a plurality of times, the number of repetition is the same as the number of the handover branches 
related to the terminal. The information elements marked by *2 in Figure 452 may be repeated a plurality of times, the 
number of repetition is the same as the number of the calls related to the terminal. The Handover branch ID element in 

40 Figure 452 is used to uniquely identify the route by which an access link is carried. 

[0664] A HANDOVER BRANCH DELETION response confirmation is sent from the TACAF to TACF to confirm the 
HANDOVER BRANCH DELETION request indication. The detail is represented in Figure 453. 
[0665] A BEARER RELEASE request indication is sent from the TACFa to TACFv to release the access bearer. The 
detail is represented in Figure 454. 

45 [0666] An INTRA- BCFr HANDOVER BRANCH DELETION request indication is sent from the TACF to BCFr to 
request the release of the physical radio channel(s). The detail is represented in Figure 455. The asterisked information 
element in Figure 455 is included when this information flow is sent from BCFr to TACF. 

[0667] An INTRA-BCFr HANDOVER BRANCH DELETION response confirmation is a response to the INTRA-BCFr 
HANDOVER BRANCH DELETION request indication and is sent from the BCFr to TACF to indicate the release of the 
so physical radio channel (s). The detail is represented in Figure 456. 

[0668] A BEARER RELEASE response confirmation is sent from the TACFv to TACFa to confirm the BEARER 
RELEASE request indication. Tiie detail is represented in Figure 457. 
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2.4.3.5.4 INTER-CELL HANDOVER BRANCH DELETION AT LOCATIONS OTHER THAN BOUNDARY 

BETWEEN CELLS 

2.4.3.5.4.1 COMMON PROCEDURE MODULES 

5 

2.4.3.5.4.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

10 [0669] Figure 46 shows the functional model of a part of the invented system for describing the inter-cell handover 
branch deletion. 

b) INFORMATION FLOWS 

is [0670] Figure 47 shows an information flow diagram of the inter-cell handover branch deletion, executed in the com- 
munication control plane. 

2.4.3.5.4.3 DEFINITIONS OF INFORMATION FLOWS AND INFORMATION ELEMENTS 

20 [0671] Information flows in Figure 47 will be described below and information elements of the flows are represented 
in tables. 

[0672] A HANDOVER BRANCH DELETION request indication is sent from the TACF to TACAF to request to release 
the physical radio channel(s). The detail is represented in Figure 458. The information elements marked by *1 in Figure 
458 may be repeated a plurality of times, the number of repetition is the same as the number of the handover branches 
25 related to the terminal. The information element marked by *2 in Figure 458 may be repeated a plurality of times, the 
number of repetition is the same as the number of the calls related to the terminal. The handover branch ID element in 
Figure 458 is used to uniquely identify the route by which an access radio link is carried. 

[0673] A HANDOVER BRANCH DELETION response confirmation is sent from the TACAF to TACF to confirm the 
HANDOVER BRANCH DELETION request indication. The detail is represented in Figure 459. 
30 [0674] A RADIO BEARER RELEASE request indication is sent from the TACAF to BCAF to request the radio bearer 
release. The detail is represented in Figure 460. 

[0675] A RADIO BEARER RELEASE response confirmation is a response to the RAD IO BEARER RELEASE request 
indication and is sent from the BCFr to TACAF to indicate the completion of the radio bearer release. The detail is rep- 
resented in Figure 461. 

35 [0676] A H ANDOVE R CONNECTION RELEASE request indication is sent from the TACF to BCF to release the indi- 
cated bearer in the diversity handover state. The detail is represented in Figure 462. 

[0677] A HANDOVER CONNECTION RELEASE response confirmation is sent from the BCF to TACF to confirm the 
HANDOVER CONNECTION RELEASE request indication. The detail is represented in Figure 463. 
[0678] A BEARER RELEASE request indication is sent from the TACFa to TACFv to release the access bearer. The 
40 detail is represented in Figure 464. 

[0679] Another BEARER RELEASE request indication is sent from the TACF to BCF to request the bearer release. 
The detail is represented in Figure 465. 

[0680] A BEARER RELEASE response confirmation is sent from the BCF to TACF to confirm the BEARER RELEASE 
request indication. The detail is represented in Figure 466. 

45 [0681] A BEARER-AND-RADIO-BEARER RELEASE request indication is sent from the TACF to BCFr to request the 
bearer between the BCF and BCFr and the radio bearer. The detail is represented in Figure 467. The asterisked infor- 
mation element in Figure 467 is included when this information flow is sent from BCFr to TACF. 
[0682] A BEARER-AND-RADIO-BEARER RELEASE response confirmation is a response to the BEARER-AND- 
RADIO-BEARER RELEASE request indication and is sent from the BCFr to TACF to indicate the completion of the 

so release of the bearer and the radio bearer. The detail is represented in Figure 468. 

[0683] A BEARER RELEASE response confirmation is sent from the TACFv to TACFa to confirm the BEARER 
RELEASE request indication. The detail is represented in Figure 469. 



69 



EP0 978 958A1 



2.4.3.5.5 INTRA-CELL BRANCH REPLACEMENT HANDOVER 

2.4.3.5.5.1 COMMON PROCEDURE MODULES USED 

5 2.4.3.5.5.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

[0684] Figure 48 shows the functional model of a part of the invented system for describing the intra-cell branch 
10 replacement handover. 

b) INFORMATION FLOWS 

[0685] Figure 49 shows an information flow diagram of the intra-cell branch replacement handover executed in the 
is communication control plane. 

2.4.3.5.5.3 DEFINITIONS OF INFORMATION FLOWS AND INFORMATION ELEMENTS 

[0686] Information flows in Figure 49 will be described below and information elements of the flows are represented 
20 in tables. 

[0687] A BEARER SETUP request indication is sent from the TACFa to TACFv to setup an access bearer. The detail 
is represented in Figure 470. The asterisked information element in Figure 470 identifies the bearer between the BCFa 
and BCFv. 

[0688] An INTRA-BCFr HANDOVER BRANCH REPLACEMENT request indication is sent from the TACF to BCFr to 

25 request to set up new physical radio channel(s). 

[0689] An INTRA-BCFr HANDOVER BRANCH REPLACEMENT response confirmation is a response to the INTRA- 
BCFr HANDOVER BRANCH REPLACEMENT request indication and is sent from the BCFr to TACF to indicate the 
completion of the setup of the physical radio channel(s). The detail is represented in Figure 471. The information ele- 
ment marked by *1 in Figure 471 maybe repeated a plurality of times, the number of repetition is the same as the 

30 number of the radio links to be setup. 

[0690] An INTRA-BCFr HANDOVER BRANCH REPLACEMENT PROCEEDING request indication is seat from the 
BCFr to TACF to indicate that the request of the handover branch replacement is accepted. The detail is represented in 
Figure 472. 

[0691] A RADIO BEARER SETUP REQUEST request indication is sent from the visited TACF, which controls the 
35 newly assigned radio bearer, to the anchor TACFa to request to setup the radio bearer between the mobile terminal and 
BCFr controlled by the visited TACF. The detail is represented in Figure 473. 

[0692] A NON-SOFT HANDOVER EXECUTION request indication is sent from the TACF to TACAF to notify of a non- 
soft handover execution request initiation and to request to replace an existing radio channel by the designated physical 
radio channel. The detail is represented in Figure 474. The information element marked by *1 in Figure 474 may be 
40 repeated a plurality of times, the number of repetition is the same as the number of the handover branches related to 
the terminal. The information element marked by *2 in Figure 474 may be repeated a plurality of times, the number of 
repetition is the same as the number of the calls related to the TACF. 

[0693] A RADIO BEARER SETUP request indication is sent from the TACAF to BCAF to request to setup a radio 
bearer. The detail is represented in Figure 475. 
45 [0694] A RADIO BEARER SETUP response confirmation is a response to the RADIO BEARER SETUP request indi- 
cation and is sent from the BCAF to TACAF to indicate the completion of the radio bearer setup. The detail is repre- 
sented in Figure 476. 

[0695] A RADIO BEARER RELEASE request indication is sent from the TACAF to BCAF to request the radio bearer 
release. The detail is represented in Figure 477. 
so [0696] A RADIO BEARER RELEASE response confirmation is a response to the RADIO BEARER RELEASE request 
indication and is sent from the BCAF to TACAF to indicate the completion of the radio bearer release. The detail is rep- 
resented in Figure 478. 

[0697] A BEARER SETUP response confirmation is sent from the TACFa to TACFv to confirm the establishment of 
the access bearer. The detail is represented in Figure 479. 
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2.4.3.5.6 INTER-CELL BRANCH REPLACEMENT HANDOVER 

2.4.3.5.6. 1 COMMON PROCEDURE MODULES USED 

5 2.4.3.5.6.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

[0698] Figure 50 shows the functional model of a part of the invented system for describing the inter-cell branch 
10 replacement handover. 

b) INFORMATION FLOWS 

[0699] Figure 51 shows an information flow diagram of the inter-cell branch replacement handover executed in the 
is communication control plane. 

2.4.3.5.6.3 DEFINITIONS OF INFORMATION FLOWS AND ASSOCIATED INFORMATION ELEMENTS 

[0700] Information flows in Figure 51 will be described below and information elements of the flows are represented 
20 in tables. 

[0701 ] A HANDOVER CONNECTION SETUP request indication is sent from the TACFa to BCFa to notify of a hando- 
ver initiation and to request to set up a new handover link. The detail is represented in Figure 480. The information ele- 
ment marked by *1 in Figure 480 is mandatory in case that the network has more than one handover mode. 
[0702] A HANDOVER CONNECTION SETUP response confirmation is sent from the BCF to TACF to confirm the 
25 HANDOVER CONNECTION SETUP request indication. The detail is represented in Figure 481 . The asterisked infor- 
mation element in Figure 481 identifies the bearer between the BCFa and BCFv 

[0703] A BEARER SETUP request indication is sent from the TACFa to TACFv to set up a new handover link. The 
detail is represented in Figure 482. The asterisked information element in Figure 482 identifies the link between the 
BCFa and BCFv. There may be another functional entity for transition of link between the BCFa and BCFv. The expres- 

30 sion of inter-BCF link should be studied further. 

[0704] Another BEARER SETUP request indication is sent from the TACF to BCF to request a new handover link in 
the network. The detail is represented in Figure 483. The asterisked information element in Figure 483 identifies the link 
between the BCFa and BCFv. There may be another functional entity for transition of link between the BCFa and BCFv. 
The expression of inter-BCF link should be studied further. 

35 [0705] A BEARER SETUP response confirmation is sent from the BCF to TACF to confirm a BEARER SETUP 
request indication. The detail is represented in Figure 484. The asterisked information element in Figure 484 identifies 
the link between the BCF and BCFr. There may be another functional entity for transition of link between the BCFa and 
BCFv. The expression of inter-BCF link should be studied further. 

[0706] A BEARER-AND-RADIO-BEARER SETUP request indication is sent from the TACF to BCFr to request to set 
40 up a bearer between the BCF and BCFr and a radio bearer. The detail is represented in Figure 485. 

[0707] A RADIO BEARER SETUP PROCEEDING request indication is sent from the BCFr to TACF to indicate that 
the request of the access radio link setup is accepted and that the BCFr starts setting up the access radio link. The 
detail is represented in Figure 486. i 

[0708] A RADIO BEARER SETUP REQUEST request indication is sent from the visited TACF, which controls the 
45 newly assigned access radio link, to TACFa to request to set up the access radio link between the mobile terminal and 
the BCFr controlled by the visited TACF. The detail is represented in Figure 487. 

[0709] A NON-SOFT HANDOVER EXECUTION request indication is sent from the TACF to TACAF to notify of a 
NON-SOFT HANDOVER EXECUTION request indication and to request to replace an existing physical radio channel 
by a designated physical radio channel. The detail is represented in Figure 488. The information element marked by *1 

so in Figure 488 may be repeated a plurality of times, the nurrfoer of repetition is the same as the number of the handover 
branches related to the terminal. The information element marked by *2 in Figure 488 may be repeated a plurality of 
times, the number of repetition is the same as the number of the access links related to the TACF. 
[071 0] A RADIO BEARER SETUP request indication is sent from the TACAF to BCAF to request to set up an access 
radio link. The detail is represented in Figure 489. 

55 [0711] A RADIO BEARER SETUP response confirmation is a response to the RADIO BEARER SETUP request indi- 
cation and is sent from the BCAF to TACAF to indicate the completion of the setup of the access radio link. The detail 
is represented in Figure 490. 

[0712] A RADIO BEARER RELEASE request indication is sent from the TACAF to BCAF to request to release the 



71 



EP 0 978 958 A1 



access radio link. The detail is represented in Figure 491 . 

[0713] A RADIO BEARER RELEASE response confirmation is a response to the RADIO BEARER RELEASE request 
indication and is sent from the BCAF to TACAF to request to release the access radio link, "me detail is represented in 
Figure 492. 

5 [0714] A BEARER-AND-RADIO-BEARER SETUP response confirmation is a response to the BEARER-AND- 
RADIO-BEARER SETUP request indication and is sent from the BCFr to TACF to indicate the completion of the setup 
of the access radio link and the link between the BCFr and BCF. The detail is represented in Figure 493. 
[0715] A BEARER SETUP response confirmation is sent from the TACFa to TACFv to confirm the establishment of 
the handover link. The detail is represented in Figure 494. 

10 [0716] A HANDOVER CONNECTION RELEASE request indication is sent from the TACF to BCFa to request to 
remove the indicated handover link. The detail is represented in Figure 495. 

[0717] A HANDOVER CONNECTION RELEASE response confirmation is sent from the BCF to TACF to confirm the 
HANDOVER CONNECTION RELEASE request indication. The detail is represented in Figure 496. 
[0718] A BEARER RELEASE request indication is sent from the TACFa to TACFv to request to release the handover 
is link in the network. The detail is represented in Figure 497. 

[071 9] Another BEARER RELEASE request indication is sent from the TACF to BCF to request to release the hando- 
ver link in the network. The detail is represented in Figure 498. 

[0720] A BEARER RELEASE response confirmation is sent from the BCF to TACF to confirm the BEARER RELEASE 
request indication. The detail is represented in Figure 499. 
20 [0721] A BEARER-AND-RADIO-BEARER RELEASE request indication is sent from the TACF to BCFr to request to 
release the access link or handover link between the BCF and BCFr and between BCAF and BCF. The detail is repre- 
sented in Figure 500. The asterisked information element in Figure 500 us included when this information flow is sent 
from the BCFr and TACF. 

[0722] A BEARER-AND-RADIO-BEARER RELEASE response confirmation is a response to the BEARER-AND- 
25 RADIO-BEARER RELEASE request indication and is sent from the BCFr to TACF to indicate the completion of the 
release of the access link or hand over link. The detail is represented in Figure 501 . 

[0723] A BEARER RELEASE response confirmation is sent from the TACFv to TACFa to confirm the BEARER 
RELEASE request indication. The detail is represented in Figure 502. 

30 2.4.3.5.7 ACCH REPLACEMENT 

[0724] Figure 790 shows a part of the invented system for describing the ACCH replacement. In Figure 790, a service 
control center 1 , connected to a public network (not shown), controls or manages a plurality of (two in the example in 
Figure 790) mobile service switching centers 2a and 2b. Each mobile service switching center 2a or 2b is connected 
35 with a base station controller 3a or 3b via a plurality of lines. The base station controller 3a controls base stations 6a to 
6d while the base station controller 3b controls base stations 6e to 6h. The base stations 6a to 6h possess radio zones 
5a to 5h, respectively, and one of the base stations is communicable with a mobile station 7 when the mobile station 7 
visits the corresponding radio zone. 

[0725] In relation to Figure 790, assume that the mobile station 7 exists in the radio zone 5b and treats a plurality of 
40 calls using a plurality of traffic channels. At least one ACCH (associated control channel), utilizing the same radio 
resources as those for one of the traffic channels that are used for voice or data transportation, is necessary. 
[0726] As already described at section 2.2.2, one ACCH (for example, ACCH1 in Figure 790) is selected in accord- 
ance with the invented system, and is used for transporting all of the control signals involved in the mobile station 7. 
Therefore, it is possible to reduce the number of hardware elements for transporting control signals in comparison with 
45 the case that the calls respectively utilize multiple ACCHs. In addition, it is possible to exclude complicated control pro- 
cedures, e.g., adjustment of the transportation order of control information in the plurality of ACCHs. 
[0727] In such a communications system, however, when a set of wireless communication resources involved in the 
single ACCH is released due to the release of one of the traffic channels by the ending of the call, it is difficult to secure 
the ACCH to continue the other call. The same problem may occur when the transmission rate in the ACCH is altered. 
so Consequently, when the radio resources involved in the employed ACCH are released due to a connection or call 
release, and when another call should be continued, ACCH replacement is necessary. ACCH replacement is also nec- 
essary when altering the transmission rate in the ACCH. 

[0728] Accordingly, in addition to sharing the single ACCH by the multiple traffic channels for realizing the multiple 
calls simultaneously by the single mobile station 7, when the single set of wireless communication resources involved 
55 in the single ACCH is released, the ACCH is replaced by another ACCH. 
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2.4.3.57.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

5 [0729] Figure 52 shows functional entities involved in the ACCH replacement of the invented system. As shown in 
Figure 52, these functional entities can be categorized into two types: the first type is functional entities arranged in the 
mobile terminal and the second type is functional entities arranged in the visited network including base stations. The 
arrangement and the function of the functional entities will be described next briefly. 

[0730] The mobile communications control center 2a or 2b in Figure 790 is provided with a CCFa (call control function) 
10 which is a functional entity for controlling call and connection. The index "a" of CCFa is the abbreviation of "anchor" that 
means it is fixed at the start of communication and does not move although the mobile terminal 6 moves. 
[0731] The base station controller 3a or 3b is provided with a TACFa (terminal access control function) and a BCFa 
(bearer control function). The TACFa is a functional entity for controlling the access from the network to the mobile sta- 
tion 7 and for instructing the activation and release of the ACCH. The BCFa (bearer control function) is a functional 
is entity for controlling the bearer. As similar to above, the index "a" is the abbreviation of "anchor." 

[0732] The base station controller 3a or 3b, which may be the same as or other than that with the TACFa and BCFa, 
is provided with a TACFv and BCFv. The index V is the abbreviation of Visited." 

[0733] Either of the base stations 4a and 4b that are controlled by the base station controller with the TACFv and BCFv 
is provided with a BCFr (bearer control function) associated with radio bearers. The BCFr controls radio bearers and 

20 activates and releases the ACCH . 

[0734] The mobile terminal 6 is provided with a TACAF (terminal access control agent function) and BCAF (bearer 
control agent function). The TACAF is a functional entity for controlling the access to the mobile terminal and for instruct- 
ing the release and establishment of the ACCH. The BCAF is a functional entity for controlling the radio bearer of the 
mobile terminal and for executing the release and establishment of the ACCH. 

25 [0735] The index "1 " or "2" is attached to the functional entities. The index "1 " means that the corresponding entity is 
served for the first call while the index "2" means that the corresponding entity is served for the second call within a plu- 
rality of calls that the mobile terminal 7 is carrying out. 

(b) INFORMATION FLOWS 

30 

[0736] Figures 53 and 54 cooperate to form an information flow diagram showing the ACCH replacement procedure 
executed in the communication control plane. 

2.4.3.5.7.3 DEFINITIONS OF INFORMATION FLOWS AND ASSOCIATED INFORMATION ELEMENTS 

35 

[0737] Information flows and information elements in Figures 53 and 54 will be described below and the information 
elements are represented in tables. With reference to the sequential chart in Figures 53 and 54, the ACCH replacement 
procedure will be described. 

[0738] The ACCH replacement procedure in Figures 53 and 54 is started under the condition described below. 

40 

(a) Previously, a mobile station has treated first and second calls using traffic channels TCH1 and TCH2. 

(b) Then, the first call by the traffic channel TCH1 is now being finished. 

(c) An associated control channel ACCH1 and the traffic channel TCH1 have used the same radio resources. The 
associated control channel ACCH1 has been commonly shared by the first and second calls for transporting control 

45 signals. 

(d) The traffic channel TCH1 and the associated control channel ACCH1 will be released due to the finish of the 
first call. However, it is necessary to maintain the second call through the traffic channel TCH2, so that another 
associated control channel is necessary. Therefore, it is necessary to replace the associated control channel 
ACCH1 by another associated control channel ACCH2 that uses the same resources as of the traffic channel 

so TCH2. 

[0739] Consequently, the procedure illustrated in Figures 53 and 54 starts under the conduction, which is the same 
as that, under which the procedure illustrated in Figure 262 starts. In other words, the chart shown in Figures 53 and 
54 is essentially the same as the chart in Figure 262, but represents in more detail the replacement procedure for 
55 replacing the radio bearer between the BCAF1 and BCFM for the first call with the radio bearer between the BCAF2 
and BCFr2 for the second call. 

[0740] When conditions (a) to (d) are satisfied, a trigger fa replacing ACCH is generated as represented in Figure 53. 
If the TACFa detects this trigger, the TACFa determines a connection to which the ACCH should be newly setup and 
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then sends a HANDOVER CONNECTION SETUP request indication to the BAFa to notify of the handover initiation and 
to request to setup an ACCH. As represented in Figure 503, the HANDOVER CONNECTION SETUP request indication 
contains a BCF-TACF relationship ID element, base station ID element, and handover mode element. In the tables, "M" 
is the abbreviation of mandatory while "0" is the abbreviation of optional. The handover mode element in Figure 503 is 

5 mandatory when the network has more than one handover mode. 

[0741 J As shown in Figure 53, the BCFa captures a DHT for the new ACCH, and then sends a HANDOVER CON- 
NECTION SETUP response confirmation to the TACFa to confirm the HANDOVER CONNECTION SETUP request 
indication. The HANDOVER CONNECTION SETUP response confirmation contains a TACF-BCF relationship ID ele- 
ment and inter-BCF bearer ID element as represented in Figure 504. The bearer ID element in Figure 504 identifies the 

10 bearer between the BCFa and BCFv. 

[0742] Then, a BEARER SETUP request indication is sent from the TACFa to TACFv2, which corresponds to the sec- 
ond call, to setup an access bearer for the ACCH. The BEARER SETUP request indication contains a TACF-BCF rela- 
tionship ID element, inter-BCF bearer ID element, base station ID element and user information rate element as 
represented in Figure 505. The bearer ID element identifies the bearer between the BCFa and BCFv. 

15 [0743] The TACFv2 sets up a to-BTS short cell connection for the ACCH and then selects a link reference which is 
the same as of that the traffic channel TCH2 for realizing the second call. Then, the TACFv2 sends another BEARER 
SETUP request indication to the BCFv2. The BEARER SETUP request indication requests to setup a bearer for 
ACCH2 which is associated with the traffic channel TCH2. The BEARER SETUP request indication contains a TACF- 
BCF relationship ID element, inter-BCF bearer ID element, user information rate element, and base station ID element, 

20 as represented in Figure 506. The bearer ID element identifies the bearer between the BCFa and BCFv. 

[0744] Once the BCFv2 receives the BEARER SETUP request indication, the BCFv2 setup the requested bearer and 
sends a BEARER SETUP response confirmation to the TACFv2 to confirm the BEARER SETUP request indication. 
The BEARER SETUP response confirmation contains a TACF-BCF relationship ID element and BCF-BCFr bearer ID 
element as represented in Figure 507. The bearer ID identifies the bearer between the BCF and BCFr. 

25 [0745] When the TACFv2 receives the BEARER SETUP response confirmation, TACFv2 sends a BEARER-AND- 
RADIO-BEARER SETUP request indication to the BCFr2 to request to setup a bearer between the BCF and BCFr and 
a radio bearer from the ACCH. The BEARER-AND-RADIO-BEARER SETUP request indication contains a TACF-BCFr 
relationship ID element and bearer ID element as represented in Figure 508. 

[0746] Upon the reception of the BEARER-AND-RADIO-BEARER SETUP request indication, the BCFr2 in light of the 
30 link reference specifies the traffic channel TCH2 and enables to start the transmission through ACCH2. Then, the 
BCFr2 sends a RADIO BEARER SETUP PROCEEDING request indication to the TACFv2 to indicate that the request 
of the radio bearer setup is accepted and that the BCFr starts setting up the radio bearer for ACCH2. The RADIO 
BEARER SETUP PROCEEDING request indication contains a TACF-BCFr relationship ID as represented in Figure 
509. 

35 [0747] Upon the reception of the RADIO BEARER SETUP PROCEEDING request indication, a RADIO BEARER 
SETUP REQUEST request indication is sent from the visited TACFv2, which controls the newly assigned radio bearer, 
to the TACFa to request to setup a radio bearer for ACCH2 between the mobile terminal and the BCFr controlled by the 
visited TACF. The RADIO BEARER SETUP REQUEST request indication contains a TACF-TACF relationship ID as rep- 
resented in Figure 510. 

40 [0748] Next, another RADIO BEARER SETUP request indication is sent from the TACFa to TACAF to notify of the 
ACCH replacement handover execution initiation and to request to replace the existing physical radio channel for the 
first call with the designated physical radio channel for the ACCH. The RADIO BEARER SETUP request indication con- 
tains a call ID as represented in Figure 51 1 . 

[0749] Upon the reception of the RADIO BEARER SETUP request indication, the TACAF as shown in Figure 54 sends 
45 BCAF2 another RADIO BEARER SETUP request indication. The RADIO BEARER SETUP request indication requests 
to setup a radio bearer for the ACCH (ACCH2) and contains a TACAF-BCAF relationship ID as represented in Figure 
512. 

[0750] Upon the reception of the RADIO BEARER SETUP request indication, the BCAF2 establishes the new ACCH 
and then sends a RADIO BEARER SETUP response confirmation to the TACAF to indicate the completion of the radio 
so bearer setup for the new ACCH. The RADIO BEARER SETUP response confirmation contains a TACAF-BCAF rela- 
tionship ID as represented in Figure 513. 

[0751] Then, the TACAF sends another RADIO BEARER SETUP response confirmation to the TACFa to indicate the 
completion of setting up of the radio bearer for the ACCH (ACCH2). The RADIO BEARER SETUP response confirma- 
tion contains a TACAF-BCAF relationship ID in the same fashion as that represented in Figure 513. 
55 [0752] Next, the TACAF sends the BCAF1 a RADIO BEARER RELEASE request indication to request to release the 
previous radio bearer. The RADIO BEARER RELEASE request indication contains a TACAF-BCAF relationship ID as 
represented in Figure 514. 

[0753] Upon the reception of the RADIO BEARER RELEASE request indication, the BCAF1 releases the previously 
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employed ACCH (ACCH1 associated with the traffic channel TCH1) and then replies a RADIO BEARER RELEASE 
response confirmation to the TACAF to indicate the completion of the radio bearer release. The RADIO BEARER 
RELEASE response confirmation contains a TACAF-BCAF relationship ID as represented in Figure 515. 
[0754] On the other hand, when receiving the RADIO BEARER SETUP response confirmation, the TACFa sends the 
5 BCFa a HANDOVER CONNECTION RELEASE request indication to request to remove the previous bearer in the soft 
handover state. The HANDOVER CONNECTION RELEASE request indication contains a TACF-BCF relationship ID 
element and released bearer ID element as represented in Figure 516. 

[0755] Upon the reception of the HANDOVER CONNECTION RELEASE request indication, the BCFa releases the 
previous DHT and sends a HANDOVER CONNECTION RELEASE response confirmation to the TACFa to confirm the 
io HANDOVER CONNECTION RELEASE request indication. The HANDOVER CONNECTION RELEASE response con- 
firmation contains a TACF-BCF relationship ID as represented in Figure 517. 

[0756] Next, the TACFa sends the TACFvl a BEARER RELEASE request indication to request to release the access 
bearer. The BEARER RELEASE request indication contains a TACF-TACF relationship ID as represented in Figure 
518. 

15 [0757] Upon the reception of the BEARER RELEASE request indication, the TACFvl sends the BCFvl another 
BEARER RELEASE request indication to request to release the bearer. The BEARER RELEASE request indication 
contains a TACF-BCF relationship ID as represented in Figure 519. 

[0758] Upon the reception of the BEARER RELEASE request indication, the BCFvl sends the TACFvl another 
BEARER RELEASE request indication to confirm the BEARER RELEASE request indication, and then release the pre- 
20 vious resources. The BEARER RELEASE response confirmation contains a TACF-BCF relationship ID element as rep- 
resented in Figure 520. 

[0759] Upon the reception of the BEARER RELEASE response confirmation, the TACFvl sends the BCFM a 
BEARER-AND-RADIO-BEARER RELEASE request indication to request to release the bearer between the BCF and 
BCFr and the radio bearer. The BEARER-AND-RADIO-BEARER RELEASE request indication contains a TACF-BCFr 
25 relationship ID element and a cause element as represented in Figure 521. The cause element is however included 
when this information element is sent from the BCFr to TACF. 

[0760] On the other hand, when receiving the BEARER-AND-RADIO-BEARER RELEASE request indication, the 
BCFM stops the transmission. Then, the BCFM sends the TACFvl a BEARER-AND-RADIO-BEARER RELEASE 
response confirmation and then releases the previous resources. The BEARER-AND-RADIO-BEARER RELEASE 
30 response confirmation is a response to the BEARER-AND-RADIO-BEARER request indication and indicates the com- 
pletion of the release of the bearer and radio bearer. The BEARER-AND-RADIO-BEARER RELEASE response confir- 
mation contains a TACF-BCFr relationship ID as represented in Figure 522. 

[0761] Upon the reception of the BEARER-AND-RADIO-BEARER RELEASE response confirmation, the TACFvl 
sends the TACFa a BEARER RELEASE response confirmation to confirm the BEARER RELEASE request indication. 

35 The BEARER RELEASE response confirmation contains a TACF-TACF relationship ID as represented in Figure 523. 
[0762] In the above description of the ACCH replacement procedure, it is omitted to describe the procedure when the 
mobile station carries out the diversity handover for simplifying the description. If the mobile station 7 (refer to Figure 
790) carries out the diversity handover, the above-mentioned functional entities (TACFvl, BCFvl, TACFv2, BCFv2, 
BCFM , BCFr2) are respectively provided with the base station controllers or the base stations, to which branches are 

40 established, and are controlled by the TACFa in the same manner as represented in Figures 53 and 54. Accordingly, 
the ACCH replacement may be executed even at the diversity handover status. In this case, information elements are 
simultaneously transported between the TACFa of all of the base station controllers and the TACAFv of the mobile ter- 
minal. 

[0763] In the ACCH replacement procedure, a wired access link is newly established between a base station control- 
45 ler at which the TACFa is disposed and a base station, and then the radio access link between the mobile terminal and 
the network is replaced. Accordingly, the ACCH replacement is accomplished. 

[0764] However, in an alteration, it is possible to replace the ACCH without the new establishment of the wired access 
link. This alteration will be described with reference to Figure 791. 

[0765] As represented in Figure 791 . a trigger for replacing ACCH is generated. If the TACFa detects this trigger, the 
so TACFa determines a connection to which the ACCH should be newly setup; and then sends an ACCH REPLACEMENT 
SETUP request indication to the TACFv2 where the new ACCH should be setup. Upon the reception of the reception, 
the TACFv2 further sends an ACCH REPLACEMENT SETUP request indication to the BCFr2. As a result the BCFr2 
sets up the new ACCH and starts transmission through the ACCH. Then, the BCFr2 replies a notification of the com- 
pletion of the ACCH setup to the TACFv2. Upon the reception of the reception of the notification, the TACFv2 sends 
55 another notification of the completion of the ACCH setup to the TACFa. The TACFa sends a RADIO ACCESS LINK 
SETUP request indication as similar to the foregoing procedure represented in Figures 53 and 54. As a result, the 
BCAF2 sets up the new ACCH while the BCAF1 releases the existent ACCH. In addition, the TACAF sends the TACFa 
a RADIO ACCESS LINK SET UP response confirmation. 
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[0766] Upon the reception of the RADIO ACCESS LINK SETUP response confirmation, the TACFa sends the TACFv! 
an ACCH RELEASE request indication. Then, the TACFvl further sends the ACCH RELEASE request indication to the 
BCFM. As a result, the BCFrl stops transmission through the existent ACCH, releases the existent ACCH and sends 
back the TACFvl an ACCH RELEASE response confirmation. Then, the TACFvl notifies the TACFa of the completion 
5 of the release of the existent ACCH. 

[0767] In this procedure, since the ACCH replacement is accomplished by the functional entities illustrated in Figure 
791 , it is not carried out to newly set up a radio access link in the network. 

2.4.3.5.8 CODE REPLACEMENT 

10 

2.4.3.5.8.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

75 [0768] Figure 55 shows the functional model of a part of the invented system for describing a code replacement. 

b) INFORMATION FLOWS 

[0769] Figure 56 shows an information flow diagram of the code replacement executed in the communication control 
20 plane. 

2.4.3.5.8.3 DEFINITIONS OF INFORMATION FLOWS AND ASSOCIATED INFORMATION ELEMENTS 

[0770] Information flows and information elements in Figure 56 will be described below and the information elements 
25 are represented in tables. 

[0771] A CODE REPLACEMENT request indication is sent from a BCFr to a TACF to request change of codes. The 
detail of the CODE REPLACEMENT request indication is represented in Figure 524. 

[0772] Another CODE REPLACEMENT request indication is sent from the visited TACF to a TACFa to request change 
of codes. The detail of the CODE REPLACEMENT request indication is represented in Figure 525. 

30 [0773] Another CODE REPLACEMENT request indication is sent from the TACF to a TACAF to request change of 
codes. The detail of the CODE REPLACEMENT request indication is represented in Figure 526. The element marked 
by *1 in Figure 526 may be repeated a plurality of times, the number of repetition is the same as the number of the 
handover branches related to the terminal. The element marked by *2 in Figure 526 may be repeated a plurality of 
times, the number of repetition is the same as the number of calls related to the TACF. 

35 [0774] Another CODE REPLACEMENT request indication is sent from the TACAF to the BCAF to request to change 
of codes. The detail of the CODE REPLACEMENT request indication is represented in Figure 527. 
[0775] A CODE REPLACEMENT response confirmation is a response to the CODE REPLACEMENT request indica- 
tion and is sent from the BCAF to the TACAF to indicate the completion of the change of codes. The detail of the CODE 
REPLACEMENT response confirmation is represented in Figure 528. 

40 [0776] Another CODE REPLACEMENT response confirmation is a response to the CODE REPLACEMENT request 
indication and is sent from the TACAF to the TACFa to confirm the CODE REPLACEMENT request indication. The 
detail of the CODE REPLACEMENT response confirmation is represented in Figure 529. 

[0777] Another CODE REPLACEMENT response confirmation is sent from the TACFa to the TACFv to confirm the 
CODE REPLACEMENT request indication. The detail of the CODE REPLACEMENT response confirmation is repre- 
ss sented in Figure 530. 

[0778] Another CODE REPLACEMENT response confirmation is sent from the TACF to the BCFr to confirm the 
CODE REPLACEMENT request indication. The detail of the CODE REPLACEMENT response confirmation is repre- 
sented in Figure 531. 

so 2.4.3.6 TRANSMISSION POWER CONTROL 

2.4.3.6.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

55 

[0779] Figure 57 shows the functional model of a part of the invented system for describing a transmission power con- 
trol. 
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b) INFORMATION FLOWS 

[0780] Figure 58 shows an information flow diagram of the transmission power control executed in the communication 
control plane. 

5 

2.4.3.6.3 DEFINITIONS OF INFORMATION FLOWS AND ASSOCIATED INFORMATION ELEMENTS 

[0781] Information flows and information elements in Figure 58 will be described below and the information elements 
are represented in tables. 

10 [0782] A CELL CONDITION REPORT request indication is sent from an MRRC to an RRC periodically to notify of the 
radio conditions of respective handover branches. The detail of the CELL CONDITION REPORT request indication is 
represented in Figure 532. 

[0783] A TRANSMISSION POWER CONTROL request indication is sent from a TACFa to TACFv to notify of the 
instructed transmission power. The detail of the TRANSMISSION POWER CONTROL request indication is represented 
15 in Figure 533. 

[0784] Another TRANSMISSION POWER CONTROL request indication is sent from a TACFv to BCFr to notify of the 
instructed transmission power. The detail of the TRANSMISSION POWER CONTROL request indication is represented 
in Figure 534. 

20 2.4.4 INFORMATION FLOWS OF MOBILITY SERVICES 

2.4.4.1 TERMINAL LOCATION UPDATING 

2.4.4.1 .1 COMMON PROCEDURE MODULES USED 

25 

[0785] Common procedure modules used within the terminal location updating service are the TMUI inquiry; the 
FPLMTS user ID retrieval, the user authentication procedure, the ciphering start time notification, and the TMUI assign- 
ment. 

30 2.4.4.1.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

[0786] Figure 59 shows the functional model of a part of the invented system for describing a terminal location updat- 

35 ing. 

b) INFORMATION FLOWS 

[0787] Figures 60 and 61 form an information flow diagram of the terminal location updating. 

40 

2.4.4.1 .3 DEFINITIONS OF INFORMATION FLOWS AND ASSOCIATED INFORMATION ELEMENTS 

[0788] Information flow in Figures 60 and 61 will be described below and information elements of the flows are rep- 
resented in tables. 

45 

Relationship rd (LRCF-LRDF) 

[0789] An LAI UPDATE request indication is sent from the visited SCF to the SDF for requesting to update the location 
area information. A response confirmation is returned to the visited SCF from the SDF to confirm the completion of 
so updating the location area information. Figure 535 represents the details of the LAI UPDATE request indication and the 
LAI UPDATE response confirmation. 

Relationship rk (SACF-LRCF) 

55 [0790] A TERMINAL LOCATION UPDATE request indication is sent from the SACF to the visited SCF for requesting 
to update the location information of the mobile terminal. A response confirmation is returned to the SACF from the vis- 
ited SCF to confirm the completion of updating the terminal location information. Figure 536 represents the details of 
the TERMINAL LOCATION UPDATE request indication and the TERMINAL LOCATION UPDATE response confirma- 
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tion. 

Relationship rl (MCF-SACF) 

[0791] Another TERMINAL LOCATION UPDATE request indication is sent from the MCF to the SACF for requesting 
to update the location information of the mobile terminal. A response confirmation is returned to the MCF from the 
SACF to confirm the completion of updating the terminal location information. Figure 537 represents the details of the 
TERMINAL LOCATION UPDATE request indication and the TERMINAL LOCATION UPDATE response confirmation. 

[Notes} 

[0792] 

1) The relationship ID element identifies the relationship between requests and responses. 

2) TMUI and TMUI assignment source ID should be used for the FPLMTS user ID element for relationships rl and 
rk. 

3) The terminal status element indicates whether the terminal can accept a call or not. 

4) The TC information is a terminal data information which indicates terminal capabilities. 

2.4.5 INFORMATION FLOWS OF SECURITY SERVICES 

2.4.5.1 USER AUTHENTICATION 

a) FUNCTIONAL MODEL 

[0793] Figure 62 shows the functional model of a part of the invented system for describing a user authentication. 

b) INFORMATION FLOWS 

[0794] Figure 63 shows an information flow diagram of the user authentication. 

c) DEFINITIONS OF INFORMATION FLOWS. INFORMATION ELEMENTS, AND FUNCTIONAL ENTITY 
ACTIONS 

[0795] Information flows and functional entity actions in Figure 63 will be described below and information elements 
of the flows are represented in tables. 

Relationship rd (LRCF-LRDF) 

[0796] An authentication information retrieval information flow is used to request the security information from the vis- 
ited LRDF for the user authentication. Figure 538 represents the detail of the AUTHENTICATION INFORMATION 
RETRIEVAL request indication and the AUTHENTICATION INFORMATION RETRIEVAL response confirmation. 

Relationship rg (LRCF-TACF) and Relationship rk{LRCF-SACF) 

[0797] An AUTHENTICATION CHALLENGE IF is used to verify the identity of the user. That is, an authentication chal- 
lenge initiated by a network is sent from LRCF to TACF/SACF for requesting the return of the authentication calculation 
result. Figure 539 represents the detail of the AUTHENTICATION CHALLENGE request indication and the AUTHENTI- 
CATION CHALLENGE response confirmation. 

Relationship rb (TACFF-TACAF) and Relationship ri (SACF-MCF) 

[0798] Another AUTHENTICATION CHALLENGE IF is used to verify the identity of the user. That is. an authentication 
challenge initiated by the network is sent from TACFF to TACAF and from SACF to MCF for requesting the return of the 
authentication calculation result. Figure 540 represents the detail of the AUTHENTICATION CHALLENGE request indi- 
cation and the AUTHENTICATION CHALLENGE response confirmation. 
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Relationship rv(UIMF-TACAF) and Relationship ry (UIMF-MCF) 

[0799] An AUTHENTICATION request indication is used to send a random number and to request to calculate a 
response with the random number and authentication key retained in the U IMF. An AUTHENTICATION response con- 
5 firmation is used to send the authentication calculation result. Figure 541 represents the detail of the AUTHENTICA- 
TION request indication and the AUTHENTICATION response confirmation. 

2.4.5.2 CIPHERING START TIME NOTIFICATION 

w 2.4.5.2.1 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

[0800] Figure 64 shows the functional model of a part of the invented system for describing a ciphering start time noti- 
is fication. 

b) INFORMATION FLOWS 

[0801 ] Figure 65 shows an information flow diagram of the ciphering start time notification. 

20 

c) DEFINITIONS OF INFORMATION FLOWS, INFORMATION ELEMENTS, AND FUNCTIONAL ENTITY 
ACTIONS 

[0802] Information flows and functional entity actions in Figure 65 will be described below and information elements 
25 of the flows are represented in tables. 

Relationship rb (TACF-TACAF) 

[0803] A START CIPHERING request indication is used to request that the terminal begins to apply the encryption 
30 procedure to information transmitted between itself and the network. This needs a confirming information flow. 

Relationship rg (LRCF-TACF) 

[0804] Another START CIPHERING request indication is used to request that the terminal begins to apply the encryp- 
35 tion procedure to information transmitted between itself and the network. This needs a confirming information flow. Fig- 
ure 542 represents the details of the START CIPHERING request indication and the START CIPHERING response 
confirmation. 

Relationship rk (LRCF-SACF) 

40 

[0805] Another START CIPHERING request indication is used to request that the terminal begins to apply the encryp- 
tion procedure to information transmitted between itself and the network. This needs a confirming information flow. Fig- 
ure 543 represents the details of the START CIPHERING request indication and the START CIPHERING response 
confirmation. 

45 

Relationship rl (SACF-MCF) 

[0806] Another START CIPHERING request indication is used to request that the terminal begins to apply the encryp- 
tion procedure to information transmitted between itself and the network This needs a confirming information flow. 

50 



55 
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f 

2.4.5.3. TMUI MANAGEMENT AND USER ID RETRIEVAL 



2.4.5.3.1 TMUI ASSIGNMENT 

5 2.4.5.3.1.1 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

[0807] Figure 66 shows the functional model of a part of the invented system for describing a TMUI assignment. 

10 

b) INFORMATION FLOWS 

[0808] Figure 67 shows an information flow diagram of the TMUI assignment. In Figure 67, the relationship between 
MCF and SACF is used for the user authentication in non-call related case while the relationship between TACAF and 
is TACF is used for the user authentication in call related case. However, this could be accommodated with the relation- 
ship between MCF and SACF as well. An AUTHENTICATION INFORMATION RETRIEVAL request indication and an 
AUTHENTICATION INFORMATION response confirmation are used rf no user authentication information is available in 
the visited network. 

20 c) DEFINITIONS OF INFORMATION FLOWS, INFORMATION ELEMENTS. AND FUNCTIONAL ENTITY 

ACTIONS 

[0809] Information flows and functional entity actions in Figure 67 will be described below and information elements 
of the flows are represented in tables. 

25 

Relationship rb (TACF-TACAF) 

[0810] A TMUI ASSIGNMENT request indication is used to assign and convey the TMUI to the user after the network 
has verified the identity of the user. A response confirmation is returned for acknowledging the successful assignment 
30 of the TMUI. Figure 544 represents the details of the TMUI ASSIGNMENT request indication and the response confir- 
mation. 

Relationship rd (LRCF-LRDF) 

35 [0811] A TMUI QUERY IF is used to request a new TMUI available from the visited LRDF. Figure 545 represents the 
details of the TMUI QUERY request indication and response confirmation. 

[0812] A TMUI MODIFY request indication is used to request the visited LRDF to modify the TMUI information for the 
user. Then, a confirmation is sent after it has been modified. Figure 546 represents the details of the TMUI MODIFY 
request indication and response confirmation. 

40 

Relationship rg (LRCF-TACF) 

[081 3] Another TMUI ASSIGNMENT request indication is used to assign and convey the TMUI to the user after the 
network has verified the identity of the user. A response confirmation is returned for acknowledging the successful 
45 assignment of the TMUI. Figure 547 represents the details of the TMUI ASSIGNMENT request indication and the 
response confirmation. 

Relationship rk (LRCF-SACF) 

so [0814] Another TMUI ASSIGNMENT request indication is used to assign and convey the TMUI to the user after the 
network has verified the identity of the user. A response confirmation is returned for acknowledging the successful 
assignment of the TMUI. Figure 548 represents the details of the TMUI ASSIGNMENT request indication and the 
response confirmation. 

55 Relationship rl (SACF-MCF) 

[0815] Another TMUI ASSIGNMENT request indication is used to assign and convey the TMUI to the user after the 
network has verified the identity of the user. A response confirmation is returned for acknowledging the successful 
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assignment of the TMUI. Figure 549 represents the details of the TMUI ASSIGNMENT request indication and the 
response confirmation. 

2.4.5.3.2 USER ID RETRIEVAL 

5 

[081 6] This procedure is used to convert the TMUI to the IMUI of an FPLMTS user. This procedure is initiated by the 
newly visited network when the network receives the TMUI or a set of TMUI and TMUI assignment source ID as the 
FPLMTS user ID from the mobile terminal. When newly visited LRCF receives the TMUI or a set of TMUI and TMUI 
assignment source ID from the mobile terminal, the LRCF should analyze which procedure (selected from the following 
w procedures) would be executed. 

1) Terminal Location Registration and Update 

Case A) TMUI has been assigned by the newly visited LRDF 
is Case B) TMUI has been assigned by another LRDF 



In this rule, case B is not described. 
2) Mobile Originating Call 

20 3) Unsuccessful Case: If the newly visited network cannot retrieve successfully (e.g., loses TMUI), then the newly 
visited network attempts to retrieve the FPLMTS user's IMUI from the UIMF 

2.4.5.3.2.1 INFORMATION FLOW DIAGRAM 

25 [081 7] Figure 68 shows an information flow diagram of the user ID retrieval. 

2.4.5.3.2.2 INFORMATION FLOWS AND ASSOCIATED INFORMATION ELEMENTS 
Relationship rd (LRCF-LRDF) 

30 

[0818] An IMUI RETRIEVAL request indication is used to retrieve an IMUI on the basis of its corresponding TMUI. 
This information flow is sent from the LRCF to the LRDF in the same network An IMUI RETRIEVAL response confir- 
mation is a response to the request indication. The details of the IMUI RETRIEVAL request indication and response 
confirmation are represented in Figure 550. In case that a call is originated from the mobile terminal, the TMUI assign- 
35 ment source ID element in Figure 550 is not included. 

Relationship rl (SACF-LRCF) 

[081 9] Another IMUI RETRIEVAL request indication is used to retrieve the IMUI from the mobile terminal. This infor- 
40 mation flow is used only when the network does not convert the TMUI of the FPLMT user into the IMUI. This information 
flow is sent from the SCF to the SACF in the visited network. An IMUI RETRIEVAL response confirmation is a response 
to the request. The details of the IMUI RETRIEVAL request indication and response confirmation are represented in 
Figure 551. 

45 Relationship rk (MCF-SACF) 

[0820] Another IMUI RETRIEVAL request indication is used to retrieve the IMUI from the mobile terminal. This infor- 
mation flow is used only when the network does not convert the TMUI of the FPLMT user into the IMUI. This information 
flow is sent from the SACF to the MCF in the visited network. An IMUI RETRIEVAL response confirmation is a response 
so to the request. The details of the IMUI RETRIEVAL request indication and response confirmation are represented in 
Figure 552. 

Relationship rg (TACF-LRCF) 

55 [0821 ] Another IMUI RETRIEVAL request indication is used to retrieve the IMUI from the mobile terminal. This infor- 
mation flow is used only when the network does not convert the TMUI of the FPLMT user into the IMUI. This information 
flow is sent from the LRCF to the TACF in the visited network. An IMUI RETRIEVAL response confirmation is a 
response to the request. The details of the IMUI RETRIEVAL request indication and response confirmation are repre- 
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10 



sented in Figure 553. 
Relationship rb (TACAF-TACF) 

[0822] Another IMUI RETRIEVAL request indication is used to retrieve the IMUI from the mobile terminal. This infor- 
mation flow is used only when the network does not convert the TMUI of the FPLMT user into the IMUI. This information 
flow is sent from the TACF to the TACAF in the visited network An IMUI RETRIEVAL response confirmation is a 
response to the request. The details of the IMUI RETRIEVAL request indication and response confirmation are repre- 
sented in Figure 554. 

2.4.6 SDL DIAGRAMS 



[0823] SDL diagrams for functional entities (Figures 254 to 258) complies with IMT-2000 Recommendation Draft 
Q.FIF. Scenario 3 in the access link setup procedure, however, shall not be applied in this document. The number 
is attached in the texts on the information flow transmission/reception between FEs in the SDL diagrams indicates the 
FEA number in the ITU Recommendation Draft Q.FIF. 

2.5 PROTOCOL SPECIFICATIONS 

20 2.5.1 REFERENCE CONFIGURATION 

[0824] The correlation between physical node configuration and functional entities in the invented system is repre- 
sented in Figure 69. The system is provided with radio interfaces and BTS-MCC interfaces to specify the protocol. 

25 2.5.2 RADIO INTERFACE SPECIFICATION 

2.5.2.1 GENERAL 

[0825] Section 2.5.2 describes layer 1 -3 protocol specifications for the radio interface. 

30 

2.5.2.2 LAYER 1 

[0826] The description in connection with layer 1 protocol is omitted. 
35 2.5.2.3 LAYER 2 

2.5.2.3.1 GENERAL 

[0827] Layer 2 consists of a LAC (link access control) sub-layer and a MAC (medium access control) sub-layer. The 
40 LAC sub-layer consists of a layer-3-coordination sub-sub-layer and an LLC (logical link control) sub-sub-layer. Figure 
70 shows the signaling layer 2 protocol architecture over the radio interface. Figure 71 shows a sample frame structure 
for the BSC function termination. 

2.5.2.3.1.1 LAC (LINK ACCESS CONTROL) SUB-LAYER 

45 

[0828] The LAC transfers variable length service data units (SDUs) between users at layer 2 with high reliability. 

2.5.2.3.1.1.1 LAYER-3-COORDINATION SUB-SUB-LAYER 

so [0829] The layer-3-coordination sub-sub-layer performs primitive/parameter mapping between LLC and layer 3. and 
disassembles/assembles a layer data unit to/from LLG SDUs. 

2.5.2.3.1.1.2 LLC (LOGICAL LINK CONTROL) SUB-SUB-LAYER 

55 [0830] The LLC sub-sub-layer offers a high-reliability transfer function using error control, flow control, and so on. 
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2.5.2.3.1.2 MAC (MEDIUM ACCESS CONTROL) SUB-LAYER 

[0831] The MAC sub-layer detects an error of LLC PDUs and disassembles/assembles an LLC PDU to/from layer 1 
frames. 

5 

2.5.2.3.2 FUNCTIONS 

2.5.2.3.2.1 FUNCTIONS OF LAC (LINK ACCESS CONTROL) SUB-LAYER 

w 2.5.2.3.2.1.1 LAYER-3-COORDINATION SUB-SUB-LAYER 

a) SIGNALING LAYER 3 PDU ASSEMBLY AND DISASSEMBLY 

[0832] This function provides for assembling a signaling layer 3 data unit from LLC PDUs and for disassembling a 
is signaling layer 3 PDU to LLC PDUs. 

b) LINK CONTROL 

[0833] This function specifies the layer 3 entity which should process the LAC SDU with the SAPL The application 
20 should be studied further. 

c) CODE TYPE IDENTIFICATION 

[0834] This function identifies the code type when adopting the hybrid ARQ. 

25 

2.5.2.3.2.1 .2 LLC (LOGICAL LINK CONTROL) SUB-SUB-LAYER 

a) SEQUENCE INTEGRITY 

30 [0835] This function preserves the order of LLC SDUs that were submitted for transfer by this layer. 

b) ERROR CORRECTION BY SELECTIVE RETRANSMISSION 

[0836] Through a sequencing mechanism, the receiving LLC entity can detect missing LLC SDUs. This function cor- 
35 rects the sequence errors by means of retransmission. 

c) FLOW CONTROL 

[0837] This function allows an LLC receiver to control the rate at which a peer LLC transmitter entity may send infbr- 
40 mation. 

d) ERROR REPORTING TO LAYER MANAGEMENT 

[0838] This function indicates to layer management errors which have occurred. 

45 

e) KEEP ALIVE 

[0839] This function verifies that two peer LLC entities participating in a link are remaining in a link connection estab- 
lished state even in the case of a prolonged absence of data transfer. 

50 

f) LOCAL DATA RETRIEVAL 

[0840] This function allows the local LLC user to retrieve in-sequence SDUs which have not yet been released by the 
LLC entity. 

55 

g) CONNECTION CONTROL 

[0841] This function performs the establishment release, and resynchronization of an LLC link. It also allows the 
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transmission of variable length user-to-user information without a guarantee of delivery. 

h) TRANSFER OF USER-DATA 

5 [0842] This function is used for the conveyance of user data between users of the LLC. LLC supports both assured 
and unassured data transfer. 

i) PROTOCOL ERROR DETECTION AND RECOVERY 

10 [0843] This function detects errors and recovers from errors in the operation of the protocol, 
j) STATUS REPORTING 

[0844] This function allows a transmitter peer entity and a receiver peer entity to exchange status information. 

15 

2.5.2.3.2.2 FUNCTIONS OF MAC (MEDIUM ACCESS CONTROL) SUB-LAYER 

a) CRC ERROR DETECTION AND HANDLING 

20 [0845] This function provides for detecting and handling LLC PDU corruption by means of CRC. Corrupted LLC PDUs 
are discarded. 

b) ASSEMBLY+ AND DISASSEMBLY OF LLC PDU OR BTS LAYER 3 PDU FROM/TO LAYER 1 FRAMES 

25 [0846] This function provides for assembling an LLC PDU or BTS layer 3 PDU from layer 1 frames and for disassem- 
bling an LLC PDU or BTS layer 3 PDU to layer 1 frames. 

[0847] "mis function includes the padding function to extend the length of the MAC PDU to an integer multiple of the 
length of layer 1 frames. Before transferring through the RACH, a sequence number should be attached in order to pre- 
vent the MAC PDU from being received twice. 

30 

c) ADDRESS CONTROL 

[0848] This function identifies the logical link in the RACH/FACH, e.g., for respective mobile terminals, using a per- 
sonal identity system. 

35 

d) IDENTITY OF SIGNAL CONTENT 

[0849] This function classifies information, transmitted over the RACH, FACH, and UPCH, into user information or 
control information. 

40 

e) IDENTITY OF TERMINATING NODE 

[0850] This function classifies nodes, where signals are terminated, into the BTS function node and the BSC function 
node. 

45 

2.5.2.3.3 FORMATS AND PARAMETERS OF DATA UNITS 

2.5.2.3.3.1 FORMAT AND PARAMETERS OF PDUs IN LAC SUB-LAYER 

so 2.5.2.3.3.1.1 LAYER 3 COMPATIBLE SUB-SUB-LAYER PDU 

a) SAPI (SERVICE ACCESS POINT IDENTIFIER) 

[0851] This indicates to layer 3 the type of service provided by layer 2. This parameter is represented in Figure 555. 

55 

b) ST 

[0852] This parameter is attached to layer 3 compatible sub-sub-layer PDUs when disassembling a layer 3 PDU to 
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those. This parameter is referred for future assembling a layer 3 PDU estimation from those in the correct order. This 
parameter is represented in Figure 556. 

c) CODE TYPE INDICATOR 

5 

[0853] This parameter indicates the type of code to adopt the hybrid ARQ. The adoption shall depend on the version. 
This parameter is represented in Figure 557. 

d) RESERVED PARAMETER 

w 

[0854] This parameter indicates the version of layer-3-coordination sub : sub-layer, and so on. This parameter is rep- 
resented in Figure 558. 

2.5.2.3.3.1.2 LLCPDUs 

15 

2.52.3.3.1.2.1 TYPES OF LLC PDUs 

[0855] Various types of LLC protocol data units (PDUs) are listed in Figures 559 and 560. Definitions of the types of 
LLC PDUs will be described below. 

20 

a) BGN PDU (BEGIN) 

[0856] The BGN PDU is used to establish an LLC link between two peer entities. The BGN PDU requests to clear 
peer's transmitter and receiver buffers, and to initialize peer's transmitter and receiver state variables. 

b) BGAK PDU (BEGIN ACKNOWLEDGE) 

[0857] The BGAK PDU is used to acknowledge the acceptance of a layer 2 link setup request from a peer. 
30 c) BGREJ PDU (BEGIN REJECT) 

[0858] The BGREJ PDU is used to reject the layer 2 link setup request of the peer LLC entity. 

d) END PDU (END) 

35 

[0859] The END PDU is used to release an LLC link between two peer entities. 

e) ENDAK PDU (END ACKNOWLEDGE) 

40 [0860] The ENDAK PDU is used to acknowledge the release of an LLC link. 

f) RS PDU (Resynchronization) 

[0861] The RS PDU is used to resynchronize the buffers and data transfer state variables. 

45 

g) RSAK PDU (RESYNCHRONIZATION ACKNOWLEDGE) 

[0862] The RSAK PDU is used to acknowledge the acceptance of a resynchronization requested by the peer LLC 
entity. 

50 

h) ER PDU (ERROR RECOVERY) 

[0863] The ER PDU is used to recover from protocol error. 
55 i) ERAK PDU (ERROR RECOVERY ACKNOWLEDGE) 

[0864] The ERAK PDU is used to acknowledge the recovery from protocol error. 
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j) SD PDU (SEQUENCED DATA) 

[0865] The SD PDU is used to transfer, through an LLC link, sequentially numbered PDUs containing information 
fields provided by the LLC user. 

5 

k) POLL PDU (STATUS REQUEST) 

[0866] The POLL PDU is used to request, across an LLC link, to transmit status information about the peer LLC entity. 

w I) STAT PDU (SOLICITED STATES RESPONSE) 

[0867] The STAT PDU is used to respond to a status request (POLL PDU) received from a peer LLC entity. It contains 
information regarding the reception status of SD PDUs and SD-with-POLL PDUs in the N(R) field, credit information for 
the peer transmitter in the N(MR) field, and the sequence number in the N(PS) field corresponding to the POLL PDU or 
15 SD-with-POLL PDU to which it is in response. 

m) USTAT PDU (UNSOLICITED STATES RESPONSE) 

[0868] The USTAT PDU is used to respond to a detection of one or more new missing SD PDUs, based on the exam- 
20 ination of the sequence number of the SD PDU. It contains information regarding the reception status of SD PDUs in 
the N(R) field, and an upper-window-edge information for the peer transmitter in the N(MR) field. 

n) SD-with-POLL PDU (SEQUENCED DATA WITH STATUS REQUEST) 

25 [0869] The SD-with-POLL PDU is used to transfer, through an LLC link, sequentially numbered PDUs containing infor- 
mation fields provided by the LLC user and used to request status information about the peer LLC entity. 

0) UD PDU (UNNUMBERED DATA PDU) 

30 [0870] The UD PDU is used for unassured data transfer between two LLC users. When an LLC user requests unac- 
knowledged information transfer, the UD PDU is used to send information to the peer without affecting LLC states or 
variables. The UD PDUs does not carry a sequence number and therefore, the UD PDU may be lost without notification. 

p) MD PDU (MANAGEMENT DATA PDU) 

35 

[0871] The MD PDU is used for transferring unassured management data between two management entities. When 
a management entity requests unacknowledged information transfer, the MD PDU is used to send information to the 
peer management entity without affecting LLC states or variables. The MD PDU does not carry a sequence number and 
therefore, the MD PDU may be lost without notification. 
40 [0872] An invalid PDU is a PDU which: 

a) has an unknown PDU type code, or 

b) is not of the proper length of the PDU belonging to the stated types. 

45 [0873] Invalid PDUs shall be discarded without notification to the sender. No additional action is taken as a result of 
the invalid PDU Length violations from items b) and c) above are reported to layer management. 

2.5.2.3.3.1.2.2 FORMATS OF LLC PDUs 

so [0874] Figures 72 through 88 represents formats of LLC PDUs. As listed at section 

2.5.2.3.3.1.2.1, there are 16 types of PDUs. 

[0875] Figure 72 represents the sequenced data PDU (SD PDU). Figure 73 represents the sequenced-data-wrth-sta- 
55 tus-request PDU (SD-with-POLL PDU). Figure 74 represents the POLL PDU. Figure 75 represents the STAT PDU. Fig- 
ure 76 represents the USTAT PDU. Figure 77 represents the UD PDU and MD PDU. Figure 78 represents the Begin 
PDU (BGN PDU). Figure 79 represents the BGAK PDU. Figure 80 represents the BGREJ PDU. Figure 81 represents 
the END PDU. Figure 82 represents the ENDAK PDU. Figure 83 represents the RS PDU. Figure 84 represents the 
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RSAK PDU. Figure 85 represents the ER PDU. Figure 86 represents the ERAK PDU. Features of these formats will be 
described below. 

2.5.2.3.3.1.2.2.1 CODING CONVENTIONS 

5 

[0876] The coding of the LLC PDU conforms to the coding conventions specified in 2.1/1.361 [4]. LLC PDU is trailer 
oriented: i.e., the protocol control information is transmitted last. 

2.5.2.3.3. 1 .2.2.2 RESERVED FIELD 

W 

[0877] There is a field of reserved bits (that maybe retried to as R, Rsvd, Reserved) in each PDU. One function of the 
reserved field is to achieve the eight-bit alignment of PDU. Other functions should be studied further. When no functions 
other than the eight-bit-alignment are defined, this field shall be coded as zero. This field shall be ignored by the 
receiver. 

15 

2.5.2.3.3.1.2.2.3 PDU length 

[0878] The maximum length of the information fields in SD, UD, and MD PDUs is k octets. The maximum value of k 
should be studied further. The value of k is determined at part of size negotiation procedures carried out outside LLC, 
20 upon bilateral agreement, and may be specified by another Recommendation utilizing LLC, or may be derived from the 
maximum length PDU size for protocols using LLC. The minimum value of k is 0 octets. 

[0879] The maximum length of a variable length SSCOP-UU field is j octets. The maximum value of j should be stud- 
ied further. The value of j is determined upon bilateral agreement, may be specified by another Recommendation utiliz- 
ing LLC, or maybe derived from requirements of protocols utilizing LLC. The minimum value of j is 0 octets. 

25 

2.5.2.3.3.1.2.2.4 CODINGS OF STAT AND USTAT PDU 

[0880] Each USTAT PDU contains two list elements. Each STAT PDU contains zero or more list elements. Transmitted 
STAT messages may be segmented into two or more STAT PDUs. 
30 [0881 ] The processing of a STAT PDU does not rely on information in other STAT PDUs. This is true even for the case 
when multiple STAT PDUs are generated in response to a single POLL PDU, and one or more of these PDUs are lost. 
[0882] The span list items in the STAT and USTAT PDUs are odd or even elements of a list used for selective retrans- 
mission requests. Every odd element represents the first PDU of a missing gap, and every even element, except pos- 
sibly the last one, represents the first PDU of a received sequence. 

35 

2.5.2.3.3.1.2.2.5 STATES OF LLC PROTOCOL ENTITY 

[0883] This sub-clause describes the states of an LLC entity. These states are used in the specification of the peer- 
to-peer protocol. The states are conceptual and reflect general conditions of the LLC entity in the sequences of signals 
40 and PDU exchanges with its user and peer, respectively. In addition, other conditions are used in the description, in 
order to avoid identification of additional states, as detailed in the SDLs. The basic states will be described below. 

State 1 (Idle) 

45 [0884] Each LLC entity is conceptually initiated in an Idle state (state 1) and returns to this state upon the release of 
a connection. 

State 2 (Outgoing Connection Pending) 

so [0885] An LLC entity requesting a connection with a peer is in an outgoing connection pending state (state 2) until it 
receives an acknowledgement from the peer. 

State 3 (Incoming Connection Pending) 

55 [0886] An LLC entity that has received a connection request from a peer and is waiting for its user's response is in an 
incoming connection pending (state 3). 
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State 4 (Outgoing Disconnection Pending) 

[0887] An LLC entity requesting release of the peer-to-peer connection is in an outgoing disconnection pending state 
(state 4) until it receives a confirmation that the peer entity has released and transitioned to the Idle state (State 1). 

5 

State 5 (Outgoing Resynchronization Pending) 

[0888] An LLC entity requesting resynchronization of the connection with a peer is in an outgoing resynchronization 
pending state (state 5). 

w 

State 6 (Incoming Resynchronization Pending) 

[0889] An LLC entity that has received a resynchronization request from a peer and is waiting for its user's response 
is in an incoming resynchronization pending state (state 5). 

is 

State 7 (Outgoing Recovery Pending) 

[0890] An LLC entity requesting recovery of an existing connection with a peer is in an outgoing recovery pending 
state (state 7). 

20 

State 8 (Recovery Response Pending) 

[0891] An LLC entity that has completed recovery, notified its user of the recovery completion, and is awaiting for a 
response from the user is in a recovery response pending state (state 8). 

25 

State 9 (Incoming Recovery Pending) 

[0892] An LLC entity that has received a recovery request from a peer and is waiting for its user's response is in an 
incoming recovery pending state (state 9). 

30 

State 10 (Data Transfer Ready) 

[0893] Upon successful completion of the connection establishment, resynchronization, or error recovery procedures, 
both peer LLC entities will be in a data transfer ready state (state 10) and possible to execute data transfer. 

35 

2.5.2.3.3. 1 .2.4 LLC STATE VARIABLES 

[0894] This section describes the state variables used in the peer-to-peer protocol. SD and POLL PDUs are sequen- 
tially and independently numbered, and may have a value between "0" and n minus 1 (where n is the modulus of the 

40 sequence number). The modulus equals to 2 8 , and therefore, the sequence number cycles through the entire range 
between 0 through 2 s - 1 . Therefore, all arithmetic operations on the following state variables or sequence numbers are 
affected by the modulus: VT(S), VT(PS), VT(A), VT(PA), VT(MS), VR(R), VR(H), and VR(MR). When performing arith- 
metic comparisons of transmitter variables, VT(A) is assumed as a base. When performing arithmetic comparisons of 
receiver variables, VR(R) is assumed as a base. In addition, the state variables VT(SQ) and VR(SQ) use the modulo 

45 256 arithmetic. The LLC sub-sub-layer manages the following state variables at the transmitter. 

a) VT(S) - SENDING STATE VARIABLE 

[0895] This is the sequence number of an SD PDU to be transmitted next in the first transmission (i.e.. except for that 
so in retransmissions). This is incremented after sending each SD PDU in the first transmission (i.e. except in retransmis- 
sions). 

b) VT(PS) - POLL SENDING STATE VARIABLE 

55 [0896] This is the sequence number of a POLL PDU or SD-with-POLL PDU transmitted currently. This is incremented 
before transmission of the next POLL or SD-with-POLL PDU. 
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c) VT(A) - ACKNOWLEDGEMENT STATE VARIABLE 

[0897] This is the sequence number of an in-sequence SD PDU which is expected to be acknowledged next and 
forms the lower edge of an acknowledgement window acknowledging SD PDUs. The variable VT(A) is updated in 
5 response to the acknowledgement of transmitted SD PDUs. 

d) VT(PA) - POLLACKNOWLEDGEMENT STATE VARIABLE 

[0898] This is the sequence number of an STAT PDU which is expected to be received next and forms the lower edge 
10 of the acknowledgement window constituted of STAT PDUs. If an STAT PDU containing an invalid parameter at the 
N(PS) field is received, a recovery is initiated or release is performed. Otherwise, if an acceptable STAT PDU is 
received, the variable VT(PA) is updated on the basis of. the parameter at the N(PS) field of the received STAT PDU. 

e) VT(MS) - MAXIMUM SENDABLE VALUE STATE VARIABLE 

15 

[0899] This is the sequence number of an SD PDU which is not allowed by the peer receiver. That is, the peer receiver 
sequentially receives SD PDUs having sequence numbers up to VT(MS) - 1 . The variable VT(MS) represents the upper 
edge of the transmission window. The transmitter should not transmit a new SD PDU rf the current VT(S) reaches 
VT(MS). The variable VT(MS) is updated in response to the reception of a USTAT PDU, STAT PDU, BGN PDU, BGAK 
20 PDU, RS PDU, RSAK PDU, ER PDU, or ERAK PDU. 

f) VT(PD) - POLL DATA STATE VARIABLE 

[0900] When acknowledgements are outstanding, this state variable represents the number of SD PDUs transmitted 
25 between transmissions of two POLL PDUs, or the number of SD PDUs transmitted before the transmission of the first 
POLL PDU after a POLL timer became active. The variable VT(PD) is incremented in response to the transmission of 
an SD PDU, and reset to zero in response to the transmission of a POLL PDU. 

g) VT(CC) - CONNECTION CONTROL STATE VARIABLE 

30 

[0901] This variable represents the number of unacknowledged BGN, END, ER, or RS PDUs. The variable VT(CC) 
is incremented in response to the transmission of a BGN, END, ER, or RS PDU. If an END PDU is transmitted in 
response to a protocol error, LLC sub-sub-layer does not wait for receiving the corresponding ENDAK PDU and enters 
directly into state 1 (Idle) and the variable VT(CC) is not incremented 

35 

h) VT(SQ) - TRANSMITTER CONNECTION SEQUENCE STATE VARIABLE 

[0902] This state variable is used to allow the receiver to identify retransmitted BGN, ER, and RS PDUs. This state 
variable is initialized to "0" in response to creation of the LLC process and incremented and then mapped into the N(SQ) 
40 field of a BGN, RS, or ER PDU before the initial transmission of the BGN, RS, or ER PDU as represented in Figures 78, 
83 and 85. 

[0903] Additionally, the LLC sub-sub-layer manages the following state variables at the receiver. 

a) VR(R) - RECEPTION STATE VARIABLE 

45 

[0904] This state variable is the sequence number of an in-sequence SD PDU expected to be received next. This var- 
iable is incremented in response to the reception of the next SD PDU. 

b) VR(H) - HIGHEST EXPECTED RECEPTION STATE VARIABLE 

50 

[0905] This state variable is the highest number among sequence numbers of in-sequence SD PDUs in a transmis- 
sion window expected to be received next. The variable VR(H) may be updated in response to the reception of a new 
SD PDU or in response to the reception of a POLL PDU. 

55 c) VR(MR) - MAXIMUM RECEIVABLE VALUE STATE VARIABLE 

[0906] This is the sequence number of an SD PDU which is not allowed by the receiver. That is. the receiver sequen- 
tially receives SD PDUs having sequence numbers up to VR(MR) - 1 . The receiver should discard the SD PDU having 
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the parameter in the N(S) field being equal to or more than VR(MR). It is possible that the reception of such an SD PDU 
causes the transmission of a USTAT PDU. Updating manner of the variable VR(MR) can be optional with the device, 
but the variable VR(MR) should not be less than VR(H). 

5 d) VR(SQ) - RECEIVER CONNECTION SEQUENCE STATE VARIABLE 

[0907] This state variable is used to identify retransmitted BGN, ER, and RS PDUs. In reaction to the reception of a 
BGN, ER, or RS PDU, this state variable is compared with the value in the N(SQ) field of the received BGN, ER, or RS 
PDU, and then the value in the N(SQ) field is allocated to the variable VR(SQ). In the comparison, if they are different, 
10 the PDU is processed and the variable VR(SQ) is set to the parameter in the N(SQ) field. If they are equal to each other, 
the PDU is identified as a retransmitted one. 

2.5.2.3.3.1.2.5 LLC PDU PARAMETER FIELDS 

15 a) N(S) 

[0908] The variable VT(S) is mapped to the N(S) field of a new SD, SD-with-POLL, or POLL PDU whenever the new 
SD, SD-with-POLL, or POLL PDU is generated as represented in Figures 72-74. 

20 b) Information field 

[0909] The information field of an SD, SD-with-POLL, MD, or UD PDU represented in Figures 72, 73, or 77 is mapped 
from the "message unit" parameter of an AA-DATA, MAA-UNITDATA, or AA-UNITDATA request. Afterward, the informa- 
tion in this field is mapped again to a "message unit" parameter of an corresponding AA-DATA, MAA-UNITDATA, or AA- 
25 UNITDATA indication. 

c) N(PS) 

[0910] After the variable VT(PS) has been incremented, the variable VT(PS) is mapped to the N(PS) field of an SD- 
30 with-POLL or POLL PDU whenever the SD-with-POLL or POLL PDU is generated as represented in Figures 73 and 74. 
In addition, the receiver of an SD-with-POLL or POLL PDU maps the contents of the N(PS) field of the received SD- 
with-POLL or POLL PDU into the N(PS) field of an STAT PDU as represented in Figure 75. To facilitate error recovery 
procedures, in addition to the mapping of the variable VT(PS) into the N(PS) field of the SD-with-POLL or POLL PDU, 
the SD-with-POLL or POLL PDU including the N(PS) field is stored in the transmitter buffer whenever the PDU is sent. 

35 

d) N(R) 

[091 1 ] The variable VR(R) is mapped to the N(R) field of a STAT or USTAT PDU whenever the STAT or USTAT PDU 
is generated as represented in Figures 75 and 76. 

40 

e) N(MR) 

[0912] The variable VR(MR) is mapped to the N(MR) field of an STAT, USTAT, RS, RSAK, ER, ERAK, BGN, or BGAK 
PDU whenever such a PDU is generated as represented in Figures 75, 76, 78, 79, 83, 84, 85, and 86. This variable is 
45 the basis for credit granting by the receiver. 

f) SSCOP-UU 

[0913] The SSCOP-UU in a BGN, BGAK, BGREJ, END or RS PDU in Figures 78-81 , and 83 is mapped to and from 
so the "SSCOP-UU" parameter of the corresponding SSCOP signal. 

g) SOURCE BIT (S) 

[0914] In an END PDU, the source bit (S) field in Figure 81 conveys information as to whether the originator of the 
55 release initiation was the SSCOP user or the SSCOP itself. When the transmission of an END PDU is initiated by the 
user, this bit is set to "0." However, when the transmission of an END PDU is initiated by the SSCOP, this bit is set to 
"1." This bit is mapped into the "source" field of an AA-RELEASE indication. 
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h) N(SQ) 

[091 5] This f ield carries the connection sequence value. The variable VT(SQ) is mapped to the N(SQ) field of a new 
BGN, RS, or ER PDU whenever the new BGN, RS, or ER PDU is transmitted. The parameter in this field is used by the 
5 receiver with the variable VR(SQ) to identify retransmitted BGN, RS, and ER PDUs. 

i) PDU TYPE FIELD 

[0916] Codings with respect to the PDU type field is represented in the list formed by Figures 559 and 560. 

w 

2.5.2.3.3.1.2.6 LLC TIMER 

[091 7] Description with respect to the LLC timer will be omitted. 
15 2.5.2.3.3.1.2.7 LLC PROTOCOL PARAMETERS 

[0918] LLC protocol parameters will be described below. 

a) Max-CC 

20 

[091 9] This is the maximum number of the state variable VT(CC) and corresponds to the maximum limit of transmis- 
sions of a BGN, END, ER, or RS PDU. 

b) Max-PD 

25 

[0920] This is the maximum number of the state variable VT(PD) before sending a POLL PDU and resetting VT(PD) 
to zero.- 

c) Max-STAT 

30 

[0921] This is the maximum number of list elements which can be contained in an STAT PDU. When the number of 
list items exceeds the Max-STAT, the STAT message shall be segmented. All of the PDUs carrying the segments made 
from an STAT message, except possibly the last one, contain Max-STAT list items. This parameter is not used for length 
check by the receiver of an STAT PDU, but is only used by the sender of the STAT message for segmentation purposes. 
35 This parameter should be an odd integer greater than or equal to 3. The default value of the Max-STAT should be stud- 
ied further. This parameter can be changed dependency on the device. 

[0922] The default value causes the STAT PDU to fill six ATM cells using AAL type 5 common part. In addition, the 
total length of a STAT PDU should not exceed the maximum length of an SD PDU. 

40 d) Clear-buffers 

[0923] This parameter is set upon connection establishment. It holds one of two values indicating "Yes" or "No," 
respectively. If this parameter is set to "Yes," the LLC sub-sub-layer can clear its transmission buffer and release trans- 
mission queue in response to a connection release. If this parameter is set to "No," the LLC sub-sub-layer can not clear 
45 its transmission buffer and release transmission queue even if connection release occurs. Additionally, if this parameter 
is set to "No," the LLC sub-sub-layer cannot clear selectively acknowledged messages from its transmission buffer if 
older ones are still outstanding. 

e) Credit 

50 

[0924] This parameter is used to coodinate credit notifications to layer management. When the LLC sub-sub-layer is 
blocked from transmitting a new SD or SD-with-POLL PDU due to insufficient credit, the credit parameter is assigned 
the value indicating "No." When the LLC sub-sub-layer is permitted to transmit a new SD or SD-with-POLL PDU, the 
credit parameter is assigned to the value indicating "Yes." The credit parameter is initially assigned "Yes." 
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2.5.2.3.3.1.2.8 LLC CREDIT AND FLOW CONTROL 

2.5.2.3.3.1.2.8.1 CREDIT AND PEER-TO-PEER FLOW CONTROL 

[0925] Credit is granted by the LLC receiver to allow the peer LLC transmitter to transmit new SD or SD-with-POLL 
PDUs. The process by which a receiver entity determined credit is optional, but is related to the buffer availability and 
the bandwidth and delay of the connection. 

[0926] The variable VR(MR) is contained in the N(MR) field of each of BGN, BGAK, RS, RSAK. ER, ERAK, STAT and 
USTAT PDUs sent by the receiver, and then conveyed to the transmitter. The content of the N(MR) field is read out and 
stored as the variable VT(MS) at the transmitter. The variable VR(MR) sent to the transmitter is the sequence number 
of SD or SD-with-POLL PDU that the receiver will not accept. 

[0927] The transmitter does not transmit any SD or SD-with-POLL PDU having the sequence number which exceeds 
the credit allowed. The receiver discards any SD or SD-with-POLL PDUs having the sequence number which exceeds 
the credit allowed. In one case, reception of such an SD or SD-with-POLL PDU may cause the transmission of a USTAT 
PDU. 

[0928] Previously granted credit can be reduced in order for the receiver to perform f tow control, but the receiver credit 
variable VR(MR) cannot be reduced below the variable VR(H). In other words, if a receiver has accepted and acknowl- 
edged the receipt of the SD or SD-with-POLL PDU having the sequence number which is VR(H) - 1, the credit value 
VR(MR) must be greater than or equal to VR(H). 

[0929] The lower bound of the operating window according to the LLC protocol is the variable VT(A) while the upper 
bound thereof is VT(MS) - 1 . The modulus of the protocol limits the sequence number range of the operating window 
to 2 8 - 1 . Therefore, the acceptable sequence number (granted credit) at the receiver by the modulo arithmetic must be 
a value between VR(H) and VR(R) - 1. If VR(MR) = VR(R) = VR(H) , the operating window size is zero. If 
VR(MR) = VR(R) - 1 , the operating window size is maximum. 

[0930] The LLC receiver allocates a buffer to support each connection. In principle, the available receiver buffer 
should match or exceed the credit granted to the transmitter to avoid the discard of successfully transmitted data. How- 
ever, if limitted buffers are availabled for a connection, it is possible to grant credit in excess of the available buffer 
capacity. This method may obtain a higher throughput than can be achieved by limiting the credit to the availed buffer, 
with the possibility that data may need to be discarded if errors occur. The receiver cannot discard previously received 
and acknowledged, but not yet delivered, SD or SD-with-POLL PDUs. In addition, the receiver must allocate sufficient 
buffer capacity to receive and deliver the SD or SD-with-POLL PDU with the sequence number which is equal to VR(R) 
at all times unless VR(R) = VR(H) = VR(MR) . The granting of credit in excess of buffer capacity should only be per- 
formed if limited buffers are available to support the connection and if the LLC receiver can still maintain the quality of 
service (QOS) required for the connection through this method. 

2.5.2.3.3.1.2.8.2 LOCAL FLOW CONTROL 

[0931 ] LLC events, such as receptions of PDUs and external and internal signals, are normally processed in the order 
in which they occurred. However, events pertaining to the exchange of LLC link status information have priority over 
other data transfer. 

[0932] A device may detect congestion (for example, a long queuing delay) in its lower protocol layers. In this case, 
data transfer should be suspended in order to give priority to connection control messages. The means, by which an 
LLC entity decides whether or not congestion occurs, depends on the protocol environment, including protocol timer 
values. 

[0933] If an LLC entity detects a local congestion ("lower layer busy"), it can elect to suspend the servicing AA-DATA 
request signals, AA-UNITDATA request signals, and MAA-UNITDATA request signals. It can also suspend the retrans- 
mission of requested SD or SD-with-POLL PDUs. The data transfer procedures allow this to occur without causing pro- 
tocol errors. 

[0934] Therefore, when transmitting PDUs to the peer receiver, all types of PDUs except for SD PDU, SD-with-POLL 
PDU, MD PDU, and UD PDU are given highest priority. The SD PDUs, SD-with-POLL PDUs, MD PDUs, and UD PDUs 
have equal priority. Retransmissions of SD PDUs have priority over new transmissions of SD PDUs if both PDU types 
are pending. These priorities are only internal to the LLC. The LLC's local flow control at user's interface is dependent 
on the device. 

2.5.2.3.3.2. FORMAT AND PARAMETERS OF MAC PDU IN MAC SUB-LAYER AND FRAME FORMATS 

AND PARAMETERS ON LOGICAL CHANNELS 

[0935] In the following, the format and parameters of an MAC PDU in the MAC sub-layer and frame formats and 
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parameters on logical channels will be described with reference to Figures 87-94. Figure 87 represents the frame for- 
mat of an MDU and the frame format on the broadcasting channel (BCCH). Figure 88 represents the frame format of 
an MDU and the frame format on the perch channel (PCH). Figure 89 represents the frame format of an MDU and the 
format of long and short frame on the random access channel (RACH). Figure 90 represents the frame format of an 
5 MDU and the format of long frame on the forward access channel (FACH). Figure 91 represents the frame format of an 
MDU and the format of short frame on the forward access channel (FACH). Figure 92 represents the frame format of 
an MDU and the frame format on the stand alone dedicated control channel (SDCCH). Figure 93 represents the frame 
format of an MDU and the frame format on the associated control channel (ACCH). Figure 94 represents the frame for- 
mat of an MDU and the frame format on the user packet channel (UPCH). 

10 

a) PAD 

[0936] A PAD field is included in an MAC PDU (MAC sub-layer frame) to extend the length of the MAC PDU to an 
integer multiple of the length of a layer 1 frame (extend to integer octets). The bit or all bits in the PAD field should be "0." 

15 

b) LENGTH 

[0937] A length field is interposed in the MAC PDU for indicating the amount of the MAC PDU including the PAD field 
by the octet. 

20 

c) CRC 

[0938] A CRC field including an error detection code is attached to each MAC PDU, so that the receiver can detect 
any errors. The result should be used for a determination by a higher layer protocol as to whether the frame should be 
25 retransmitted. Figure 561 represents the relationship between the length of CRC fields and channels through which cor- 
responding frame is transmitted. 

d) ST 

30 [0939] A segment type (ST) field is included in each layer 1 frame for indicating that the corresponding layer 1 frame 
is the top, middle, or end of the original MAC PDU. The segment type is attached when an MAC PDU is disassembled 
to layer 1 frames, and referred when an MAC PDU evaluation is assembled from the layer 1 frames. Figure 562 repre- 
sents the bit coding of the ST field and the meaning thereof. 

35 e) OTHERS 

[0940] A Bl field in the layer 1 frame in Figure 89 includes a BCCH identity (Bl) information. Figure 563 represents the 
bit coding of the Bl field and the meaning thereof. 

[0941] An SFN field in the layer 1 frame in Figure 89 includes a system frame number (SFN) used for retrieval of the 

40 uplink long code phase and for synchronization of the super-frames. 

[0942] An uplink interference field in the layer 1 frame in Figure 89 includes uplink interference information indicating 
the uplink interference level for the corresponding sector measured most recently. Figure 564 represents the bit coding 
of the uplink interference field and the meaning thereof. However, when the measurement has not been carried out, all 
of the bits in the uplink interference field should be one. 

45 [0943] A PID field in the layer 1 frame in either of Figures 89 and 90 includes a personal identification (PID) of mes- 
sage or mobile station which is identified on the RACH or FACH. The identification shall be of the length of 16 bits. Fig- 
ure 565 represents the relationship between the usage of the PID field and the range of PID value. 
[0944] A U/C field in the layer 1 frame on the RACH, FACH or UPCH represented in either of Figures 89-91 . and 94 
includes an identifier for indicating that either of user information or control information is included in the layer 1 frame. 

so Figure 566 represents the bit coding of the U/C field and the meaning thereof. 

[0945] A TN field in the layer 1 frame on the RACH, FACH, or UPCH represented in either of Figures 89-91 , and 94 
includes an identifier of the termination or inception. Figure 567 represents the bit coding of the TN field and the mean- 
ings thereof. 

[0946] An MO field in the short layer 1 frame on the FACH represented in Figure 91 includes a bit for identifying the 
55 mode of the FACH. Figure 568 represents the bit coding of the MO field and the meanings thereof. 

[0947] A CRC field including an error detection code is attached to each layer 1 frame as represented in Figures 87 
through 94, so that the receiver can detect any errors. Figure 569 represents the relationship between the length of 
CRC fields and channels through which corresponding frames are transmitted. 
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[0948] An S field is attached to the short layer 1 frame on the RACH as represented in Figure 89. When an MAC PDU 
evaluation is assembled from the short layer 1 frames on the RACH, the bit in the S field contributes to prevent the same 
layer 1 frame from duplicating in the MAC PDU. 

[0949] A TA field in the layer 1 frames represented in either of Figures 87 though 94 includes tail bits as a convolutional 
5 code. 

[0950] A D field represented in either of Figures 90 through 92 contains dummy bits. 

2.5.2.4 LAYER 3 MESSAGES 

10 [0951] Next, messages of layer 3 of the invented system will be described. In the following description, ITU-T Recom- 
mendations X, I, and Q series will be sometimes shortened to X, I, and Q. 

2.5.2.4.1 PROTOCOL ARCHITECTURE 

15 [0952] First, the protocol architecture of layer 3 will be described. Figure 95 is a conceptual diagram representing an 
example of the radio interface protocol architecture. Among the protocol control entities in Figure 95, CC (call/connec- 
tion control) entity complies with Q.2931 and controls call and connection. MM-P entity complies with Q.2932 and man- 
ages mobility services for users, e.g., user authentication. MM-T (terminal mobility management) entity manages 
mobility services for mobile terminals, e.g., terminal location registration and user authentication. RRC (radio resource 

20 control) entity treats initiations for allocation and reservation of radio resources and for activation and deactivation of 
handover. TAC (terminal association control) entity establishes and releases signaling connections between mobile ter- 
minals and the network. 



25 



2.5.2.4.2 MESSAGE FORMATS 

[0953] Next, message formats for layer 3 will be described. 

2.5.2.4.2.1 FORMATS OF CC ENTITY MESSAGES 

30 [0954] First, CC (call/connection control) entity messages will be described. Figure 570 is a list representing various 
messages belonging to the CC entity message. In the following, the messages represented in Figure 570 will be 
described with reference to lists in Figures 571 through 628. In the lists, "M M means mandatory information element 
while w O" means optional information element. "OP means information element that will be used when ATM (asynchro- 
nous transfer mode) will be applied to radio transmission. 
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2.5.2.4.2.1.1 ALERTING MESSAGE 



[0955] First, an alerting message will be described. The alerting message is transferred from a called user to the net- 
work and then transferred from the network to a calling user in order to indicate that calling procedure of the called user 
40 is started. Figure 571 through 573 form a list representing information elements constituting the alerting message. As 
represented in this list, the significance of the alerting message is global, the channel on which the alerting message is 
carried is the ACCH, and the direction is both. 

[0956] In the list formed by Figure 571 , the connection identifier, narrow-band bearer capability information element, 
narrow-band high layer compatibility information element, mobile bearer capability information element, and mobile 
45 high layer information element should be studied further. The broad-band higher layer information element is included 
if the higher layer information selection procedure is used. The mobile bearer capability information element will be 
used when bearer capability is selected. 



2.5.2.4.2.1.2 CALL PROCEEDING MESSAGE 



[0957] Next, a call proceeding message will be described. The call proceeding message is transferred from the net- 
work to a calling user or from a called user to the network in order to indicate that requested call setup is initiated and 
no additional call setup will be accepted. Figure 574 through 576 form a list representing information elements consti- 
tuting the call proceeding message. As represented in this list, the significance of the call proceeding message is global, 
55 the channel on which the call proceeding message is carried is the SDCCH or ACCH, and the direction is both. 
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2.5.2.4.2.1 .3 CONNECT MESSAGE 

[0958] Next, a connect message will be described. The connect message is transferred from a called user to the net- 
work and from the network to a calling user in order to indicate that requested call is accepted by the called user. Figure 
5 577 through 581 form a list representing information elements constituting the connect message. As represented in this 
list, the significance of the connect message is global, the channel on which the connect message is carried is the 
ACCH, and the direction is both. 

[0959] As represented in this list if the called user wants to reply the calling user the broadband low layer compatibility 
information, the broadband low layer compatibility information element is included in the connect message from the 
w called user to the network. If the connect message from the called user to the network includes the broadband low layer 
compatibility information element, the broadband low layer compatibility information element is also included in the con- 
nect message from the network to the calling user. For the broadband low layer information negotiation, this information 
element is included in the connect message as an option, but some network may not transfer this information element 
to the calling user. 



15 
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2.5.2.4.2.1.4 CONNECT ACKNOWLEDGE MESSAGE 



[0960] Next, a connect acknowledge message will be described. The connect acknowledge message is transferred 
from the network to a called user in order to indicate that the call is established for the called user. In addition, the con- 
20 nect acknowledge message is transferred from a calling user to the network in order to enable symmetric call control 
procedure. Figure 582 is a list representing information elements constituting the connect acknowledge message. As 
represented in this list, the significance of the connect acknowledge message is local, the channel on which the connect 
acknowledge message is carried is the ACCH, and the direction is both. 

[0961] The notification identifier information element is included if the notification procedure is applied. A plurality of 
25 notification identifier information elements can be included in this message. The maximum length and the allowable 
number of the elements depend on the network. 

2.5.2.4.2.1.5 PROGRESS MESSAGE 

30 [0962] Next, a progress message will be described. The progress message is transferred from the network or either 
of users in order to indicate the event as a call progress when the interworking is taken place. Figures 583 through 585 
form a list representing information elements constituting the progress message. As represented in this list, the signifi- 
cance of the progress message is global, the channel on which the connect message is carried is the SDCCH or ACCH, 
and the direction is both. 



2.5.2.4.2. 1 .6 SETUP MESSAGE 



[0963] Next, a setup message will be described. The setup message is transferred from a calling user to the network 
and from the network to a called user in order to initiate a call setup. Figures 586 through 594 form a list representing 
40 information elements constituting the setup message. As represented in this list, the significance of the setup message 
is global, the channel on which the setup message is carried is the SDCCH or ACCH, and the direction is both. 

2.5.2.4.2. 1 .7 RELEASE MESSAGE 

45 [0964] Next, a release message will be described. The release message is transferred from the network or either of 
users in order to initiate that the device transmitting the release message has disconnected the FPLMTS connection for 
releasing connection identifier (if connection identifier is used) and call reference. The device which has received the 
release message should release the connection identifier, transmit a release complete message, and then release the 
call reference. The above description about the connection identifier will be valid only when the ATM will be applied on 

so air interface in the future. Figure 595 is a list representing information elements constituting the release message. As 
represented in this list, the significance of the release message is global, the channel on which the release message is 
carried is the SDCCH or ACCH, and the direction is both. 



2.5.2.4.2.1 .8 RELEASE COMPLETE MESSAGE 

[0965] Next, a release complete message will be described. The release complete message is transferred from the 
network or either of users in order to initiate that the device transmitting the release complete message has released 
the connection identifier (if connection identifier is used) and call reference. The connection identifier can be reused by 
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releasing. The device which has received the release complete message should release the call reference. The above 
description about the connection identifier will be valid only when the ATM will be applied on air interface in the future. 
Figure 596 is a list representing information elements constituting the release complete message. As represented in 
this list, the significance of the release complete message is local, the channel on which the release complete message 
5 is carried is the SDCCH or ACCH, and the direction is both. 

2.5.2.4.2.1.9 INFORMATION MESSAGE 

[0966] Next, an information message will be described. The information message is transferred from the network or 
w either of users in order to provide additional information, more specifically, additional information for call setup (e.g.. 
overlap sending) or various information related to call. Figure 597 is a list representing information elements constitut- 
ing the information message. As represented in this list, the significance of the information message is local (however, 
information with global significance can be transferred by this message), the channel on which the information message 
is carried is the SDCCH or ACCH, and the direction is both. 

is 

2.5.2.4.2.2 FORMAT OF MM-T ENTITY MESSAGE 

[0967] Next, MM-T (terminal mobility management) entity message will be described. 

20 2.5.2.4.2.2.1 MESSAGE BELONGING TO MM-T ENTITY MESSAGE 

[0968] Figure 598 is a list representing a message (mobility facility message) belonging to the MM-T entity message. 
[0969] With respect to various messages including the mobility facility message and others, discrimination can be car- 
ried out by the message type information element. That is, if more significant three bits in the message type information 
25 element are "01 1 the corresponding message belongs to messages prescribed in Q.2931 . In addition, if the less sig- 
nificant five bits are "00010," the corresponding message belongs to messages prescribed in Q.2932. Otherwise, the 
corresponding message is the mobility facility message. 

2.5.2.4.2.2.2 MOBILITY FACILITY MESSAGE 

30 

[0970] Figure 599 is a list representing the generic formats of the mobility facility message. As represented in this list, 
the significance of the mobility facility message is local, and the direction is both. 

2.5.2.4.2.2.3 FACILITY 

35 

[0971] The facility information of the mobility facility message in Figure 599 is constituted of various information ele- 
ments in fact. TTie contents of the facility information vary with the usage of the corresponding mobility facility message. 
Thus, lists of information elements of mobility facility message for various utilization will be explained. 

40 (a) MOBILITY FACILITY MESSAGE FROM MS TO NETWORK FOR TERMINAL LOCATION REGISTRA- 

TION 

[0972] Figures 600 and 601 form a list representing information elements constituting a mobility facility message 
transferred from the mobile station to the network for requesting terminal location registration when the terminal location 
45 should be updated or when the mobile station roams. As represented in the list, the protocol discriminator in this mes- 
sage indicates MM-T, the channel on which this message is carried is the SDCCH, and the direction is from MCF of the 
mobile station to SACF of the network. 

(b) MOBILITY FACILITY MESSAGE FROM NETWORK TO MS FOR TERMINAL LOCATION REGISTRA- 

so TION 

[0973] When the terminal location should be updated or when the mobile station roams, another type of mobility facil- 
ity message (as a response message to the request of terminal location registration) is transferred from the network to 
the mobile station. This response message can be classified into three sorts represented in three lists of Figures 602 
55 through 604, respectively. As generically represented in those lists, the protocol discriminator in each of these mes- 
sages indicates MM-T, the channel on which each message is carried is the SDCCH, and the direction is from SACF of 
the network to MCF of the mobile station. 
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(b-1)^ RESPONSE MESSAGE INDICATING "RETURN RESULT 

[0974] When the terminal location has been normally registered, the mobility facility message (response message) 
indicating "return result" represented in Figure 602 is sent. 

5 

(b-2) RESPONSE MESSAGE INDICATING "RETURN ERROR" 

[0975] When an abnormality, for example, an application error has occurred, the mobility facility message (response 
message) indicating "return error" represented in Figure 603 is sent. 

10 

(b-3) RESPONSE MESSAGE INDICATING "REJECT 

[0976] When an abnormality, for example, a discrepancy of an information element has occurred, the mobility facility 
message (response message) indicating "return error" represented in Figure 604 is sent. 

15 

(c) MOBILITY FACILITY MESSAGE FROM NETWORK TO MS FOR TMUI ASSIGNMENT 

[0977] Figure 605 is a list representing information elements constituting a mobility facility message transferred from 
the network to the mobile station for notifying the mobile station of the TMUI allocated to the mobile station. As repre- 
20 sented in the list, the protocol discriminator in this message indicates MM-T, the channel on which this message is car- 
ried is the SDCCH, and the direction is from SACF and TACF of the network to MCF and TACAF of the mobile station. 

(d) MOBILITY FACILITY MESSAGE FROM MS TO NETWORK FOR TMUI ASSIGNMENT 

25 [0978] Another type of mobility facility message (as a response message to the TMUI assignment) is transferred from 
the mobile station to the network. This response message can be classified into three sorts represented in three lists of 
Figures 606 through 608, respectively. As generically represented in those lists, the protocol discriminator in each of 
these messages indicates MM-T, the channel on which each message is carried is the SDCCH, and the direction is 
from MCF and TACAF of the mobile station to SACF and TACF of the network. 

30 

(d-1) RESPONSE MESSAGE INDICATING "RETURN RESULT 

[0979] When the TMUI has been normally assigned, the mobility facility message (response message) indicating 
"return result" represented in Figure 606 is sent. 

35 

(d-2) RESPONSE MESSAGE INDICATING "RETURN ERROR" 

[0980] When an abnormality, for example, an application error has occurred, the mobility facility message (response 
message) indicating "return error" represented in Figure 607 is sent. 

40 

(d-3) RESPONSE MESSAGE INDICATING "REJECT 

[0981 ] When an abnormality, for example, a discrepancy of an information element has occurred, the mobility facility 
message (response message) indicating "return error" represented in Figure 608 is sent. 

45 

(e) MOBILITY FACILITY MESSAGE FROM NETWORK TO MS FOR AUTHENTICATION CHALLENGE 

[0982] Figures 609 and 610 form a list representing information elements constituting a mobility facility message 
transferred from the network to the mobile station for authenticating the mobile station by the mobile service switching 
so center. As represented in the list, the protocol discriminator in this message indicates MM-T, the channel on which this 
message is earned is the SDCCH or ACCH, and the direction is from SACF and TACF of the network to MCF and 
TACAF of the mobile station. 

(f) MOBILITY FACILITY MESSAGE FROM MS TO NETWORK FOR AUTHENTICATION CHALLENGE 

55 

[0983] Another type of mobility facility message (as a response message to the authentication challenge) is trans- 
ferred from the mobile station to the network. This response message can be classified into three sorts represented in 
three lists of Figures 61 1 through 61 3, respectively. As generically represented in those lists, the protocol discriminator * 
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f in each of these messages indicates MM-T, the channel on which each message is carried is the SDCCH or ACCH, and 

r the direction is from MCF and TACAF of the mobile station to SACF and TACF of the network. 

(f-1) RESPONSE MESSAGE INDICATING "RETURN RESULT 

5 

[0984] When the authentication has been normally requested, the mobility facility message (response message) indi- 
cating "return result" represented in Figure 61 1 is sent. 



(f-2) RESPONSE MESSAGE INDICATING "RETURN ERROR" 

10 

[0985] When an abnormality, for example, an application error has occurred, the mobility facility message (response 
message) indicating "return error" represented in Figure 612 is sent. 

(f-3) RESPONSE MESSAGE INDICATING "REJECT 

15 

[0986] When an abnormality, for example, a discrepancy of an information element has occurred, the mobility facility 
message (response message) indicating "return error" represented in Figure 613 is sent. 

(g) MOBILITY FACILITY MESSAGE FROM NETWORK TO MS FOR CIPHERING START NOTIFICATION 

20 

[0987] Figure 61 4 is a list representing information elements constituting a mobility facility message transferred from 
the network to the mobile station for notifying the mobile station of ciphering onset. As represented in the list, the pro- 
tocol discriminator in this message indicates MM-T, the channel on which this message is carried is the SDCCH or 
ACCH, and the direction is from SACF and TACF of the network to MCF and TACAF of the mobile station. 

25 

(h) MOBILITY FACILITY MESSAGE FROM MS TO NETWORK FOR CIPHERING START NOTIFICATION 

[0988] Another type of mobility facility message (as a response message to the ciphering start notification) is trans- 
ferred from the mobile station to the network. This response message can be classified into three sorts represented in 
30 three lists of Figures 61 5 through 61 7, respectively. As generically represented in those lists, the protocol discriminator 
in each of these messages indicates MM-T, the channel on which each message is carried is the SDCCH or ACCH, and 
the direction is from MCF and TACAF of the mobile station to SACF and TACF of the network. 



(h-1) RESPONSE MESSAGE INDICATING "RETURN RESULT 

35 

[0989] When the ciphering onset has been normally notified, the mobility facility message (response message) indi- 
cating "return result" represented in Figure 615 is sent. 

(h-2) RESPONSE MESSAGE INDICATING "RETURN ERROR" 

40 

[0990] When an abnormality, for example, an application error has occurred, the mobility facility message (response 
message) indicating "return error" represented in Figure 616 is sent. 

(h-3) RESPONSE MESSAGE INDICATING "REJECT 

45 

[0991 ] When an abnormality, for example, a discrepancy of an information element has occurred, the mobility facility 
message (response message) indicating "return error" represented in Figure 617 is sent. 

(i) MOBILITY FACILITY MESSAGE FROM NETWORK TO MS FOR IMUI RETRIEVAL 

50 

[0992] Figure 61 8 is a list representing information elements constituting a mobility facility message transferred from 
the network to the mobile station for inquiring of the mobile station as to the IMUI of the mobile station. As represented 
in the list, the protocol discriminator in this message indicates MM-T, the channel on which this message is carried is 
the SDCCH, and the direction is from SACF and TACF of the network to MCF and TACAF of the mobile station. 

55 

0) MOBILITY FACILITY MESSAGE FROM MS TO NETWORK FOR IMUI RETRIEVAL 



[0993] Another type of mobility facility message (as a response message to the IMUI inquiry) is transferred from the 
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mobile station to the mobile service switching center. This response message can be classified into three sorts repre- 
sented in three lists of Figures 619 through 621 , respectively. As generically represented in those lists, the protocol dis- 
criminator in each of these messages indicates MM-T, the channel on which each message is carried is the SDCCH, 
and the direction is from MCF and TACAF of the mobile station to SACF and TACF of the network. 

5 

Q-1) RESPONSE MESSAGE INDICATING "RETURN RESULT 

[0994] When the IMUI has been normally inquired, the mobility facility message (response message) indicating 
"return result" represented in Figure 619 is sent. 

10 

G-2) RESPONSE MESSAGE INDICATING "RETURN ERROR" 

[0995] When an abnormality, for example, an application error has occurred, the mobility facility message (response 
message) indicating "return error" represented in Figure 620 is sent. 

15 

G-3) RESPONSE MESSAGE INDICATING "REJECT 

[0996] When an abnormality, for example, a discrepancy of an information element has occurred, the mobility facility 
message (response message) indicating "return error" represented in Figure 621 is sent. 

20 

2.5.2.4.2.3 FORMAT OF RBC ENTITY MESSAGE 

[0997] Next, RBC (radio bearer control) entity message will be describe. 
25 2.5.2.4.2.3.1 MESSAGES BELONGING TO RBC ENTITY MESSAGE 

[0998] Figure 622 is a list representing messages belonging to the RBC entity message. 
2.5.2.4.2.3.2 CLASSIFICATION OF RBC ENTITY MESSAGE 

30 

[0999] RBC entity message can be classified into two types: one relates to setup and release of bearer so as to cause 
an RBC ID to change; and the other relates to maintain bearer so as not to cause an RBC ID to change. Figure 623 is 
a list representing the classification of RBC entity message. 

35 2.5.2.4.2.3.3.1 BASIC MESSAGE FORMAT 

[1000] Next, the basic format of RBC entity message will be described. Each EBC entity message comprises a fun- 
damental part and an optional extensional part. The fundamental part is constituted of one or more message-specrf ic- 
parameter fields and one or more optional fundamental information fields. Figure 96 represents the basic format of RBC 
40 entity message. 

[1 001 ] Message-specific-parameter field in Figure 96 contains at least one unique parameter of the message. 
[1002] Each fundamental information field includes at least one parameter in conformance with the procedure that 
the message initiates. In other words, fundamental information elements in RBC entity messages vary with the neces- 
sary procedure. Fundamental information field can be used without any design change of the invented system. 
45 [1003] On the contrary; extensional information field may be used rf the performance of the invented system is 
extended. 

[1004] Operation indicator field asterisked in Figure 96 is not included in the RBC entity message for the invented 
system. If a new type of message will be used in the system due to performance extension in the future, this field will 
be used. 

50 

2.5.2.4.2.3.3.2 STRUCTURES OF FRAMES OF RBC ENTITY MESSAGE 

[1005] Figure 97 represents structures of frames of an RBC entity message. As represented in Figure 97, message- 
specif ic-parameter field is mandatory. As to each parameter, if the length is variable, the length field indicates that there 
55 is no instruction. As to each parameter, if there is not a parameter that may be used optionally, this fact is indicated by 
a bit or bits for indicating whether there is a parameter or not. 
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2.5.2.4.2.3.4 SPECIFIC MESSAGE FORMATS 

[1 006] Next, specific formats of various messages belonging to RBC entity message will be described. 

5 2.5.2.4.2.3.4.1 RADIO BEARER SETUP MESSAGE 

[1 007] First, radio bearer setup message will be described. This message is sent from the network to a mobile station 
in order to setup a radio bearer therebetween. Figure 624 is a list representing the format of radio bearer setup mes- 
sage. The protocol discriminator of the message indicates RBC, the channel on which the message is carried is the 
10 SDCCH or ACCH, and the direction is from the network to the mobile station. 

2.5.2.4.2.3.4.2 RADIO BEARER RELEASE MESSAGE 

[1 008] This message is sent from the network to a mobile station or from a mobile station to the network in order to 
15 release a radio bearer therebetween. Figure 625 is a list representing the format of radio bearer release message. The 
protocol discriminator of the message indicates RBC, the channel on which the message is carried is the ACCH, and 
the direction is from the network to the mobile station or from the mobile station to the network. 

2.5.2.4.2.3.4.3 RADIO BEARER RELEASE COMPLETE MESSAGE 

20 

[1009] This message is sent from the network to a mobile station or from a mobile station to the network in order to 
notify of the release completion of a radio bearer therebetween. Figure 626 is a list representing the format of radio 
bearer release complete message. The protocol discriminator of the message indicates RBC, the channel on which the 
message is carried is the ACCH, and the direction is from the network to the mobile station or from the mobile station 
25 to the network. 

2.5.2.4.2.3.4.4 HANDOVER COMMAND MESSAGE 

[1010] This message is sent from the network to a mobile station in order to indicate the radio bearer therebetween 
30 that is added, deleted, replaced, or substituted at handover. Figure 627 is a list representing the format of handover 
command message. The protocol discriminator of the message indicates RBC, the channel on which the message is 
carried is the ACCH, and the direction is from the network to the mobile station. 

2.5.2.4.2.3.4.4 HANDOVER RESPONSE MESSAGE 

35 

[1 01 1 ] This message is sent to respond to a handover command massage, the handover command message initiat- 
ing diversity handover (DHO) branch deletion. DHO branch addition, code replacement, and any combination thereof. 
Figure 628 is a list representing the format of handover response message. The protocol discriminator of the message 
indicates RBC, the channel on which the message is carried is the ACCH, and the direction is from the mobile station 
40 to the network. 

2.5.2.4.2.4 FORMAT OF RRC ENTITY MESSAGE 

[1012] Next, RRC (radio resource control) entity message will be described. 

45 

2.5.2.4.2.4. 1 MESSAGE BELONGING TO RRC ENTITY MESSAGE 

[1 01 3] Figure 629 is a list representing a message (radio resource facility message) belonging to the RRC entity mes- 
sage. Utilization of the ROSE (remote operations service element) protocol as the protocol for the RRC entity should 
so be studied further. Therefore, this description is based on the ROSE protocol. 

2.5.2.4.2.4.2 RRC ENTITY MESSAGE FORMAT 
2.5.2.4.2.4.2.1 MOBILITY FACILITY MESSAGE 

55 

[1014] Figure 630 is a list representing the format of the RRC facility message sent from a mobile station to the net- 
work for initiating the RRC procedure. As represented in this list the protocol discriminator of the message indicates 
RRC, the channel on which the message is carried is the SDCCH or ACCH, and the direction is from the mobile station 
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